• Post Reply Bookmark Topic Watch Topic
  • New Topic

Consuming JMS messages in FIFO order  RSS feed

 
John Fairbairn
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When multiple messages are sent to a JMS queue, in what order does the MDB container pass the messages to the message driven bean? I was hoping it would be in FIFO order but I thought I had read somewhere that this was container specific based on the application server.
Regards,
John
 
Byron Estes
Ranch Hand
Posts: 313
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are correct...
The following is an excerpt from the EJB 2.0 Specification:
15.4.6 Concurrency of message processing
A container allows many instances of a message-driven bean class to be executing concurrently, thus
allowing for the concurrent processing of a stream of messages. No guarantees are made as to the exact
order in which messages are delivered to the instances of the message-driven bean class, although the
container should attempt to deliver messages in order when it does not impair the concurrency of message
processing. Message-driven beans should therefore be prepared to handle messages that are out of
sequence: for example, the message to cancel a reservation may be delivered before the message to
make the reservation.
I think the key here is to carefully look at the messages you are sending. What are they supposed to initiate.
MDB's can't participate, as I understand it, in a transacted messaging session which would guarantee the order.
I don't think this is a big deal for most applications, it really depends upon the design.
I think you should endeavour to make the each message atomic with no dependencies on any other message. If you need more than one task to be performed or have a variable order of tasks to be performed, then you might use the message payload (...perhaps with xml) to define the sequence of actions to take. The xml payload would be like a series of commands. You could lookup a SessionBean from the MDB, pass it the xml payload which defines the variable set of tasks. The
SessionBean could parse/interpret the commands and execute the appropriate methods.
Regards,
 
John Fairbairn
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the key here is to carefully look at the messages you are sending. What are they supposed to initiate.
MDB's can't participate, as I understand it, in a transacted messaging session which would guarantee the order.
I don't think this is a big deal for most applications, it really depends upon the design.

I was looking at the messages (items in XML format) initiating database transactions (updates). But, MDB's don't look like the way to go because you can't guarantee order. Item A could have 2 updates done to it in the incorrect order.
Still humming about this...
John
 
Byron Estes
Ranch Hand
Posts: 313
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
John,
I think you need to look at the business behind the updates. Specifically, Why are you sending "related" updates in different messages? Couln't you include all the related updates in a single message payload, as defined by some xml?
<updates>
<update>Do this</update>
<update>Do that</update>
<update>Do something else</update>
</updates>
I am suggesting that you examine the business messaging strategy...
Think of it like this:
You need give a friend directions to your house over the phone.
You could dial the phone give him the first direction: Turn right onto Maple street, then hang up.
Dial the phone again, give another direction and hang up. Repeating this "x" times until all the directions are provided...
Or....
You could make one phone call (i.e. one message) and give him all the directions at once. If you subsequently change your mind and want him to meet you at your girlfriends house, you would initiate another phone call.
I think if you partition you logical messages correctly the risk of order is low. If you absolutely had to maintain control, you could maintain the date/time from the message (...not the current time from the dbms) on the persisted record. You could compare the date/time on the record to be updated to the date/time on the current message to determine if it is an "old" message.
Regards,
 
Byron Estes
Ranch Hand
Posts: 313
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You could skip the MDB and just create your own message listener which won't get pooled. You could even synchronize the method to ensure you are single threaded. That should prevent you from getting message out of order.
Regards,
 
John Fairbairn
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You could skip the MDB and just create your own message listener which won't get pooled. You could even synchronize the method to ensure you are single threaded. That should prevent you from getting message out of order.

In the app-server specific descriptor file, will specifying the max-number-of-beans = 1 and min-number-of-beans = 1 be enough to ensure I am single threaded? I would only ever have one bean in the pool. Hmm... but a new instance of this bean would probably be created every time a new message was placed on the queue so message order would still not be guaranteed... is this correct?
I wanted to make use of the message-selector functionality associated with MDB's.
John
 
Byron Estes
Ranch Hand
Posts: 313
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you decided not to use a MDB, you wouldn't put the listener code in an EJB at all. You might have a servlet with a reference to the object which you would instantiate and put into a listening loop in the init() method of your servlet. It's a bit of a hack, but if you don't feel you can adequately cover yourself from concurrency issues in MDB because you can't control the number of instances, then you need to try something.
Regrards,
 
John Fairbairn
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Byron,
Thanks for your advice.... I'll see how the MDB handles the concurrency/ordering issue in Wesphere 5.0... haven't used this app server before. Too bad there isn't a mechanism in the app-server specific descriptor file to specify the order in which messages are passed from the container to the bean - that would be great.
Thanks,
John
 
John Fairbairn
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
rather.. the order messages are grabbed off the queue by the container.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!