Hi!
My problem is as follows. I've got a JMS queue where messages lie in a strict order. My business rules require them to be proceeded exactly as they have arrived. But when I allow more then one MDB to be started simultaneously, onMessage() for the second message is often called before onMessage() for the first one. Is there any fair way to synchronize onMessage() invokations? I've tryed to master some synchronization technique inside onMessage method but this has proved a complete failure. The point is that not only one onMessage() can work faster than another, but container manager itself invokes onMessage() methods in a rather arbitrary order.
Thanks
-
how to gain synchronous start of MDB? (2 messages)
- Posted by: Dmitry Klionskiy
- Posted on: July 05 2004 07:52 EDT
Threaded Messages (2)
- response by Alex Pisarev on July 05 2004 09:46 EDT
- how to gain synchronous start of MDB? by Johnson Chen on July 06 2004 02:08 EDT
-
response[ Go to top ]
- Posted by: Alex Pisarev
- Posted on: July 05 2004 09:46 EDT
- in response to Dmitry Klionskiy
Dmitry,
if you know the number of messages you expect, you can just receive that number of messages and put either of them in a List. Each message you send should have its order number in it. After you get all the messages, you iterate through your List and sort them the way you want it. Then you process them in the right order. If you are in clustered environment, you'd better use clustered List (for example, Tangosol Coherence product can provide you with a ready implementation) or put the messages into JNDI/replicated stateful session beans or database (it could be slow, though).
Alex -
how to gain synchronous start of MDB?[ Go to top ]
- Posted by: Johnson Chen
- Posted on: July 06 2004 02:08 EDT
- in response to Dmitry Klionskiy
You can't tweak with your onMessage() to fit your goal. A consumer of the message is an MDB instance POOLED by the container, which makes its activation unpredicable. To your end, either make a single MDB instance or give an additional ordering mechanism but whose overhead/extra work may defeat your gain from multi-MDB.