tags:

views:

593

answers:

2

I have a process which involves sending a JMS message. The process is part of a transaction. If a later part of the transaction fails, a part that is after a previous part that sent the message, I need to cancel the message. One thought I had was to somehow set on the message that it is not to be picked up for a certain amount of time, and if I need to rollback, then I could go and cancel the message. Not knowing messaging, I do not know if the idea is possible. Or, is there a better idea? Thanks

+2  A: 

You can use JMS and JTA (Java Transaction API) together - see here. When doing that, the sending of a JMS message or the consumption of a received message actually happens atomically as part of the transaction commit.

What does this mean? If the transaction fails or is rolled back, the "sent" message doesn't go out and any "received" messages aren't really consumed. All handled for you by your JMS and JTA provider.

You need to be using a JMS implementation that supports JTA. Sounds like you're already using transactions, so it might be a matter of doing some configuration to make it happen (waving hand vigorously...).

I've had experience using this (BEA WebLogic 7 w/ BEA WebLogic Integration). Worked as advertised -- "the outside world" saw no impact of JMS stuff I tried unless the transaction committed successfully.

John M
+1  A: 

Hi,

What you have described is an XA transaction. This allows a transaction to scope across multiple layers i.e. JMS provider , DB or any other EIS. Most containers can be configured to use both non XA and none XA transaction so check your container settings!!

For example if you are using JMS with XA transactions the following is possible.

Start Transaction | DB Insert | Send JMS Msg | More DB Inserts | Commit Transaction <- Only at this point will the database records be inserted and the JMS message sent.

XA Tranactions are only available in full J2EE containers so XA transactions are not avaliable in tomcat.

Good luck!

Karl

Karl