| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| JMS and syncpoint |
« View previous topic :: View next topic » |
| Author |
Message
|
| JohnRodey |
 Posted: Wed Jan 04, 2006 6:12 am Post subject: JMS and syncpoint |
 |
|
Centurion
Joined: 13 Apr 2005
Posts: 103
|
In order to use syncpoint with JMS would I need to use transactions, therefore need to purchase transactional clients for all my client machines?
Or am I totally off on how to use syncpointing with JMS?
thanks |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Jan 04, 2006 6:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You only need the transactional client for two-phase transactions, not for single resource transactions.
So if you need to involve both a database transaction and an MQ syncpoint, then you need the transactional client.
If you only need syncpoint, you don't need the transactional client.
Or use the new messaging provider in WAS v6 (just to beat fjb_saper to it).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jan 04, 2006 2:28 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Thanks Jeff 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mbw |
| Posted: Thu Jan 05, 2006 3:25 am Post subject: |
|
|
Novice
Joined: 09 Dec 2004
Posts: 11
|
The Trasnactional Client License purchase is really needed when you want to do transactional work on a client (i.e. tcp/ip) connection.
If you are using a bindings connection then the 'normal' client should be ok.
To co-ordiante say a database update and MQ, with MQ as the transaction manager is only available in a bindings connection. And this is used only with the Java Classes not JMS. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 05, 2006 4:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| mbw wrote: |
The Trasnactional Client License purchase is really needed when you want to do transactional work on a client (i.e. tcp/ip) connection.
If you are using a bindings connection then the 'normal' client should be ok.
To co-ordiante say a database update and MQ, with MQ as the transaction manager is only available in a bindings connection. And this is used only with the Java Classes not JMS. |
None of this is accurate.
You can do syncpoint with MQ with the plain Java client. You can do a syncpoint with MQ with *any* MQ Client - including with JMS.
A bindings connection does not use ANY client at all. You can't establish a bindings connection on a machine that does not have a Queue Manager on it, and you can only establish a bindings connection to queue managers that are on the same machine as your program.
The Transactional Client was built explicitly to allow a client(tcp/ip) connetion to coordinate database updates and MQ transactions. And it can be used, as far as I know, with JMS as well as with the WebSphere MQ API for Java.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Jan 11, 2006 5:10 pm Post subject: Re: JMS and syncpoint |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| JohnRodey wrote: |
In order to use syncpoint with JMS would I need to use transactions, therefore need to purchase transactional clients for all my client machines?
Or am I totally off on how to use syncpointing with JMS? |
I imagine your questions re. the Extended Transactional Client is answered - but there are a few points to be made re. MQI syncpoints (also known as local transactions, local units of work or MQI transactions) as they relate to JMS session transacted/acknowledge modes.
Actually MQI syncpoints are used for the acknowledgement modes as well as for transacted mode. Besides transacted mode, the simplest case is client-acknowledge mode. Although the API semantics are different, the MQI semantics (upon which MQ JMS is built) are pretty much equivalent.
For transacted sessions, Session.commit and Session.rollback are used to commit or rollback all work on the session since the last point of consistency.
For client-ack sessions, Msg.acknowledge and Session.recover are (equivalently) used to commit or rollback all work on the session since the last point of consistency.
The semantics closest to MQI's MQCMIT and MQBACK are Session.commit and Session.recover - ie. use a transacted session. The client-ack semantics are a bit confusing (I find) because the "commit" activity is via a method on the message object, whereas the effect is applicable to the whole session.
The other acknowledgement modes use a more automatic approach to syncpoints from what I can see. Explicitly, they don't give you the level of control that is given by transactional or client-ack modes.
I hope this helps |
|
| 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
|
|
|
|
