Is it possible to store large objects (e.g. java component) in an application variable?

Question

I am developing an application right now that creates and maintains a connection to the local XMPP server in the Applications area. Connection methods are stored in cfc, which ensures that Application.XMPPConnection connects and logs in every time it is used, and uses the connection to send live events to users. As far as I can tell, this works fine. BUT it was not tested under any conditions.

My question is: Will this clarify the problems later? I only ask because I cannot find evidence of other people using application variables in this way. If I had not used the rail, I would have used the CF event gateway instead to accomplish the same task.

Answer 1

Size itself is not a problem. If you want to initialize one object for each request, you will write a lot more memory. The problem is access.

If you have a large number of queries competing for the same object, you need to measure the access time for this object or instantiation. Keep in mind that for data objects, more than one stream can read them. My understanding, however, is that when calling an object's function, it blocks that object for other threads until the function returns.

In addition, if the object maintains state, you need to think about what to do when multiple threads receive / set this data. Are you done with the race conditions?

You can consider accessing this object in the session area so that it is created only for each user (who is likely to make only one or two simultaneous requests).

Answer 2

Of course, you can use the application area to store these components if they are used by all users in different parts of the application. Now the following problems are possible:

• component size (s)
• time required to initialize, if set during application startup
• race conditions between settings / getting states of these components

Firstly, there are ways to calculate the size of a component in memory. There have been many posts lately on this topic, so it would be easy to find them. If you do not have any large structure or request stored internally, I think you're good here.

Secondly, if you do not fill this cfc with some large query from DB or do a slow parsing, you are also here.

Thirdly, pay attention to possible situations when a larger number of users change the states of these components. If so, use cflock for each component state setting.