14
Mar
09

Avoiding method timeouts in EJB Containers using Command Pattern with a JMS Queue

If you ever needed to run a complex processing in EJB that would take for example two minutes you probably have already faced the container time limitation for SessionBean methods.

This timeout (in contrast to what most think) isn’t there only to developer’s life harder. Actually, it is exactly the opposite: it is there to avoid that someone inadvertly implement a code that takes the whole server down (including your beloved application).

But there are times when long running operations are really necessary, for example a cache warmup.

MDBs are an exception

As in our project a few operations would easily violate this limitation we had to research a smart way of circumventing this limitation. During our research we found out this post on /dev/websphere blog. So we already knew that we would end up using a JMS Queue but having one Queue, MDB and so ever for each task would be a mess (not to mention that it was way too much work and not ellegant). So, that was when we came to the conclusion that what we needed was an way of having multiple tasks on top of the same infra-structure.

Command Pattern to the Rescue

We realized that by using an ObjectMessage that carried our Command object we would end up having a single queue that would handle all of our long running tasks. If there is specific context for the task processing we can have it stored in the Command Object (eg.: id of a purchase transaction that needs to be processed, or even the purchase object itself).

Sequence Diagrams for the solution

Let’s have an example, suppose we have a long running cleanup of a database that needs to be run in a timely manner. We would end up having the following flow of method calls:

JOB Submission on Working Queue

JOB Submission on Working Queue

Having the Command object implement Runnable interface is a wise idea (to avoid having another interface that is almost a Runnable clone not to mention that future JavaEE Asynch beans will probably be implemented on top of Runnable interface).

The next important part is the JOB execution, which is depicted below:

JOB execution Working MDB

JOB execution Working MDB

As mentioned on the notes, you need to be aware that the Transactional Context for the MDB MUST be Never, otherwise you’d avoid method timeouts but would still have transaction timeouts.

Another tricky part is splitting the long running task in smaller chunks that can execute under the method timeout.

As stated in the diagram, the LongRunningJOB code inside the run method is called inside the execution context of the MDB which is free from the method timeout limitation.

Signalling JOB return code

If you need to be notified that the JOB has finished its execution you’d need to have either another JOB passed as parameter to this JOB and it’ll be responsible of executing the code that would inform its return status OR have a message sent on a Temporary Queue OR the last option would be to submit a reply in another queue and have a CorrelationID link the request and the response message.

Advertisements

1 Response to “Avoiding method timeouts in EJB Containers using Command Pattern with a JMS Queue”


  1. 1 lilivier
    December 2, 2014 at 9:38 am

    It may be a problem if you need to rollback all the smallOperations. You’ll have to implement to rollbacks yourself…


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


ClustrMaps

Blog Stats

  • 358,409 hits since aug'08

%d bloggers like this: