java - How to handle order of messages in JMS?

Question

I am reviewing a client-server application written in Java. The server receives JMS messages and processes them but the messages can come in an unexpected order, and a cancel can arrive before an order message. How do you handle such a case? Do you do it in the mdb?

What are some strategies or patterns for this kind of scenario?

Answer 1

So far I know, this is refereed to as "out-of-order" delivery and is part of the quality of service (QoS) attributes of the JMS system. I don't think it's part of the JMS specification, but some provider support it maybe. That will depend on the particular JMS implementation you use.

Note however that JMS is meant to distribute messages to several consumers in a way to distribute the load. If message have to be delivered in an ordered fashion this is not possible -- it basically lead to serialization of the message delivery and message could not be processed concurrently.

The wikipedia says it better than me:

JMS queue A staging area that contains messages that have been sent and are waiting to be read. Note that, contrary to what the name queue suggests, messages don't have to be delivered in the order sent. If the message driven bean pool contains more than one instance then messages can be processed concurrently and thus it is possible that a later message is processed sooner than an earlier one. A JMS queue guarantees only that each message is processed only once.

Out-of-band cancel request is not easy to achieve with JMS then. Two ideas:

• Store a ticket which corresponds to each message in a database could be used to cancel message easily. When the message is delivered, the MDB check if the corresponding ticket is still valid. If yes, proceeds further, if not, drop the message.
• Try to set the MDB pool size to one. Maybe in this case, the delivery will be ordered. Changing the pool size is app. server specific, but most of them support per-bean pool size.

Otherwise, have maybe a look at the message store pattern. It's anyway worth checking the EAI website.