How does one guarantee the message ordering using JMS in an EJB application server? The message listeners are NOT Message Driven Beans.
Consider following scenario:
I want to transactionally publish messages from EntityBeans. Sort of like a trigger.
According to my understanding of the JMS 1.02 specification, message ordering is only guaranteed within a destination's session. If this is the case, I have to cache the JMS session associated with each topic in some sort of static class. I cannot put the session in JNDI, because JMS Sessions do not implement Serializable or Remote. Caching in the static class presents fail over and scalability issues.
In any case, holding on to the session seems to contradict using JMS as a managed resource. In J2EE, this is the only way of publishing transactionally. If this is true, how do I guarantee message ordering if I must close the session between transactions.
Thanks for any help you can provide.
It is my understanding that some JMS providers will guarantee Message Order over and above the specification. Check the specific documentation for your particular JMS provider. I believe
There was a recent discussion about this on the JBoss Development list - someone was reworking the JMS stuff to guarantee message order.
Thank you for your reply.
Unfortunately, I need a solution that works across all ‘J2EE compliant’ application servers. A solution that only works with one server and not another, implies a proprietary implementation of JMS and/or JCA. I need a solution to work within the boundaries of the specifications.
Any other thoughts and/or ideas?
How about this (I forget the exact JMS terms for certain features but I think you will get the idea):
- in your JMS message define(or agree on) a property and call it something like "messageSequenceNumber"
- the sending side will set the "messageSequenceNumber" to an incrementing value like 1,2,3
- the listening side will ask for a specific message based on this property (ie. is there a message with messageSequenceNumber=3 etc).
- I would imagine that the listening side will have to be implemented in the "polling" style (ie. check for #3, if not found, sleep, check again later)
This will preserve order and insure no messages are missed.
Some obvious problems to overcome are:
- synchronization and re-synch of sender and listener sequence numbers etc.