Concurrent processing (threads) - J2EE Applications

Often we come across a question, "How do i process things asynchronously in J2EE application?" - The only answer to this question is MDB. Let's rule out the option of creating unmanaged threads on our own, because those may interrupt with the orderly shutdown of an appserver and several limitations in the context (J2EE). Like many people in the industry, i also like the MDB and feel it's the best among the others in the enterprise beans stack. The question here is, Is this enough to address all the needs of sophisticated applications?

Perhaps, in my opinion, the answer is no. I could give several use cases to back my opinion, think of performance when there's a need for couple of asynchronous process to complete a use case on a heavy load. I could throw some classic use cases, if needed.

I looked at the alternatives and realized there's no standard way to create/or get hold of a managed threads in a J2EE applications to do our business. A sophisticated web application may need to spawn its own threads to complete it's business but in today's J2EE world there's no standard or defined way yet. There are some application server vendors who may provide option for concurrent processing in a proprietary way and some initiatives in JCP to address this also, let's wait and watch the expert group take on this. The portability of application across the container is in question here.

Below is an alternative what i could think of to address this.

Architectural Solution

There's no change in the business components end and it continue to remain same. The approach for asynchronous operations has been changed from MDB to JCA RA (Resource adapter). Some may have a question of "why are we talking about JCA RA here?". The answer is, this is the only way where i could delegate the asynchronous business to J2EE container.

Here're the steps to achieve the above,

1. Create a resource adapter and get the javax.resource.spi.work.WorkManager instance from the bootstrap context (ref: javax.resource.spi.ResourceAdapter) and keep it in the memory that can be accessed by your components (you could think of getter/setter to access the same in a singleton or a similar class).

2. Package the JCA RA along with your existing J2EE application(.ear). You need to make sure your applications in the .ear, share the same classloader.

3. From your application, you could just create a javax.resource.spi.work.Work and submit the same to javax.resource.spi.work.WorkManager for execution. In the work implementation, inside run method you could write your piece of business.

References:
JCA Specification - 1.5

Some may think, how it's going to be better than MDB approach. The answer is, quiet simple, we are not doing any JNDI lookups, send and receive message etc which is not require or mandatory from the application business point of view. Think of concurrent request of say 100, if you could avoid 100*3 (assume three MDB) JNDI lookups, send and receive message activities, i bet there would be a considerable difference in performance. Because, in the above discussed JCA RA approach, you avoid all these and just invoke methods on objects and you still get the benefit of asynchronous behaviour managed by your J2EE container.

Note: The above discussed approach may be worth considering to address the asynchronous needs in a J2EE container until we have something concrete in J2EE space. I presume there are some initiatives in the JCP and JSR has been proposed to address this. Eager, to see what's coming up in J2EE 1.5 space.