| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Two Session JMS Transactionality question |
« View previous topic :: View next topic » |
| Author |
Message
|
| MQFanUK |
 Posted: Mon Jul 14, 2008 7:54 am Post subject: Two Session JMS Transactionality question |
 |
|
Newbie
Joined: 14 Jul 2008
Posts: 1
|
Hi all
We have written a small stand-alone Java application which simply moves MQ msgs from one QM to another QM (on a different machine) using JMS API. I know this is not the best practice but one of the QMs is MQ ESE and there are issues with encrytion/decryption exists when sending a msg from ESE to non-ESE QMs.. hence the App.
We have two (2) JMS sessions. We have used the JMS API to receive msgs from Q1 on QM1 and put them onto Q2 on QM2. Very simply, this is all the app needs to do and we have got this working nicely!
Now we need to add some form of roll-back to the app, i.e., if the PUT fails to the destination Q, then they want to roll-back the GET from the source Q.
At the moment, it has two steps (separate transactions).
We apparently cannot use Synchpointing as that only works if you have one (1) session. We have two invovled.
Does anyone have advice on a simple way to cater for this? We've started looking into XA transactions as a possibility and this
seems promising. However, we've been told that it is quite involved if the app is stand-alone and not running on a server.
Any advice much appreciated!
Cheers
-Craig |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Jul 14, 2008 3:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Easy: have both your sessions being transacted.
Keep the receiving session open uncommitted until the sending session is committed, then commit the receiving session.
On any exception rollback both sessions.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| atheek |
| Posted: Thu Sep 18, 2008 2:37 am Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
| fjb_saper wrote: |
Easy: have both your sessions being transacted.
Keep the receiving session open uncommitted until the sending session is committed, then commit the receiving session.
|
This solution does ensure that messages wont get lost, but you cant have "exactly-once" quality of service. There is a possibility of duplicate messages, consider the scenario where appln crashes after sender commits and before receiver does so. If you are using single phase commit, this is the best you can achieve. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
