Static methods in JNDI ObjectFactory
I am trying to solve a simple problem, in what is turning out to be a slightly convoluted way. I take the convolutions to be a warning sign that I may be trying to do something illicit (from a Java EE standpoint). What I would like to know is whether there is anything seriously wrong with the approach I am taking here.
I would like to be able to assign a "ticket number" to long-running asynchronous background tasks (initiated by JMS messages and processed by MDBs), which can be used to check on the status of a task.
Each MDB receives the ticket number as part of the message that initializes it, and while running periodically calls a method on a TaskMonitor object, referencing the ticket number, to update its status. Clients calling Session Bean methods can discover what the current progress of a task is by obtaining the TaskMonitor object and requesting information using the same ticket number. This way we can do things like display a progress bar in an Ajax client (for example).
The TaskMonitor object is a simple in-memory hashtable of ticket numbers and status/progress indicators. It is registered as a custom resource via JNDI: both task-processing MDBs and clients wanting to check up on the status of a task must obtain the TaskMonitor object instance via a JNDI lookup.
In order to make sure that it is always the same TaskMonitor object that is obtained by boths tasks and clients requesting it via JNDI (and thus that ticket numbers and status numbers are global within the system), I therefore have a static instance of the TaskMonitor class cached in the ObjectFactory that creates TaskMonitors when one is requested via JNDI. But will this really work? What happens in a clustered environment, for example - will different nodes in the cluster in practice have different ObjectFactory instances, each with its own separate static instance of the TaskMonitor?
What I'm trying to avoid here is having to persist essentially transient information about task progress to a database. An in-memory hashtable, shared by all tasks and all clients, is fine for my purposes. I also don't want my MDBs to report back on their status via JMS, because I want clients to be able to obtain that status on demand rather than poll for update messages. But is the way I've opted for architecturally kosher?
