Is it ok to store large objects (java component for example) in an Application variable?

Question

I am developing an app right now which creates and stores a connection to a local XMPP server in the Application scope. The connection methods are stored in a cfc that makes sure the Application.XMPPConnection is connected and authorized each time it is used, and makes use of the connection to send live events to users. As far as I can tell, this is working fine. BUT it hasn't been tested under any kind of stress.

My question is: Will this set up cause problems later on? I only ask because I can't find evidence of other people using Application variables in this way. If I weren't using railo I would be using CF's event gateway instead to accomplish the same task.

Answer 1

Of course you can use application scope for storing these components if they are used by all users in different parts of application. Now, possible issues are :

1. size of the component(s)
2. time needed for initialization if these are set during application start
3. racing conditions between setting/getting states of these components

For the first, there are ways to calculate size of a component in memory. Lately there were lots of posts on this topic so it would be easy to find some. If you dont have some large structure or query saved inside, I guess you're ok here.

Second, again, if you are not filling this cfc with some large query from DB or doing some slow parsing, you're ok here too.

Third, pay attention to possible situations, where more users are changing states of these components. If so use cflock on each setting of the components the state.

Answer 2

Size itself isn't a problem. If you were to initialize one object per request, you'd burn a lot more memory. The problem is access.

If you have a large number of requests competing for the same object, you need to measure the access time for that object vs. instantiation. Keep in mind that, for data objects, more than one thread can read them. My understanding, though, is that when an object's function is called, it locks that object to other threads until the function returns.

Also, if the object maintains state, you need to consider what to do when multiple threads are getting/setting that data. Will you end up with race conditions?

You might consider handling this object in the session scope, so that it is only instantiated per user (who, likely, will only make one or two simultaneous requests).