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.

Rappel

Answer 1

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).

Solicitous

thanks for your answers. i may need to consider the scenario of multiple threads accessing the object, but i think the way its set up right now is pretty good. the only object that is stored in the Application scope and shared among all users is an XMPP connection object (created by the Smack library). it is called upon to send very quick xmpp commands to a local openfire server. would the <cflock> tag be of help in this case? – Rappel

Imagine 500 requests queued up, waiting for the single connection to get free. (If you use cflock.) Depending on various factors, this may cause a huge bottleneck. – Monro

Even if CFLOCK isn't used (it's mostly outmoded) CF is thread-safe since MX (6). Multiple threads reading the same data location don't have to wait, but calling functions will cause them to queue. At least, that's my understanding. – Solicitous

Ben, that's interesting (the lock on function call). Would you happen to have some more resource explaining this? – Autarchy

@DustMason - What does the library documentation say about this class? In other words, is a single XMPPConnection even intended to be used by multiple users/threads ..? – Plovdiv

thanks everyone. after reading a little bit i think the setup i have will scale ok for now. there is only one fast command that could actually cause race conditions and if CF is thread safe then i think we are ways from having a problem just yet – Rappel

Answer 2

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.

Matronna