Question

I’m designing a part of a Java EE 6 application, consisting of EJB3 beans. Part of the requirements are multiple parallel (say a few hundred) long running (over days) database hunts. Individual hunts have different search parameters (start time, end time, query filter). Parameters may get changed over time.

Currently I’m thinking of the following:

• SearchController (Stateless Session Bean) formulates a set of search parameters, sends it off to a SearchListener via JMS
• SearchListener (Message Driven Bean) receives search parameters, instantiates a SearchWorker with the parameters
• SearchWorker (SLSB) hunts repeatedly through the database; when it finds something, the result is sent off via JMS, and the search continues; when the given ‘end-time’ has reached, it ends

What I’m wondering now:

• Is there a problem, with EJB3 instances running for days? (Other than that I need to be able to deal with container restarts…)
• How do I know how many and which EJB instances of SearchWorker are currently running?
• Is it possible to communicate with them individually (similar to sending a System V signal to a unix process), e.g. to send new parameters, to end an instance, etc..

Answer 1

If you’re holding a huge ResultSet open for an extended period of time, you’re likely to encounter either transaction timeouts or database locking issues.

There is no builtin mechanism for determining which bean instances are running in a method, so you would need to add your own mechanism. Your product might have some kind of performance monitoring that lets you know how many of each type of bean is currently running a method.

As for cross-thread communication, you would need to implement your own synchronization and periodically check in the bean method. You’ll be outside the scope of standard EJB since each parallel call to a business method will allocate a new SLSB from the pool.