| Author |
Message
|
| Ash |
 Posted: Mon Jan 21, 2002 7:04 am Post subject: |
 |
|
Novice
Joined: 07 Jan 2002
Posts: 17
|
Hi,
We have got a MQSeries client application running on Windows NT that connects to a server on Sun Solaris.
I am having a bit of a difficulty understanding how to do MQPUT's and MQGET's under syncpoint from the client connection.
Consider the following sequence:
MQCONN
MQOPEN
MQPUT
MQPUT
MQGET
MQCOMMIT
Where does the unit of work (start of syncpoint) actually begin and where does it end.
My understanding is that the MQCOMMIT marks the end of syncpoint and all puts and gets till that point will be committed.
What I want to know is at which call does the syncpoint start...is it at MQCONN,MQOPEN or MQPUT.
Also, what happens if you have multiple connections and do a MQCOMMIT from one of the connections...does it only commit the puts and gets that happened through that connection or does it commit eveyrthing on the queue manager i.e. all activity through the other connections as well.
Much appreciated.
Regards,
Ash |
|
| Back to top |
|
 |
| bduncan |
| Posted: Mon Jan 21, 2002 3:07 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Ash,
As you noticed, MQBEGIN doesn't exist in the client API. This is because MQBEGIN is only used for XA transactions, which aren't supported through the client API. But whether you are connecting to the queue manager via a client or directly, you don't need to use MQBEGIN if you are doing transactional work that doesn't need to be under XA. In this case, when you want to being a unit of work, you simply issue an MQGET with MQGMO_SYNCPOINT or an MQPUT with MQPMO_SYNCPOINT specified, you'll implicitly start a new unit of work. Subsequent GETs or PUTs without the SYNCPOINT parameter will be done outside of this unit of work, and any GETs or PUTs with SYNCPOINT specified will occur in the SAME unit of work. At some point you will issue an MQCMIT or MQBACK to commit or rollback the unit of work.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| Ash |
| Posted: Tue Jan 22, 2002 7:08 am Post subject: |
|
|
Novice
Joined: 07 Jan 2002
Posts: 17
|
Thanks Brandon.
That clears up the picture for me.
I would appreciate a little more clarification on the connections part.
For example, I have got multiple connections to the server from a client through which I am doing MQPUT's and MQGET's under syncpoint and then I issue a MQCOMMIT from one of the connections.
Will it commit all the PUT's & GET's from all the other connections to that server or will it only commit the PUT's and GET's from that particular connection which has issued the MQCOMMIT and all the other connections will need to issue their own MQCOMMIT's.
Thanks once again for your help.
Regards,
Ash |
|
| Back to top |
|
|
| ravi |
| Posted: Fri Jan 25, 2002 1:40 pm Post subject: |
|
|
Novice
Joined: 07 Nov 2001
Posts: 16
|
Each Connection will have its own unit of work maintained. so you need to issue MQCMIT on each connection to commit the unit of work associated with it.
ravi.
|
|
| Back to top |
|
|
| StefanSievert |
| Posted: Fri Jan 25, 2002 9:02 pm Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
Ash,
that would be really disastrous if one committing application would affect other processes' unit of work, what do you think? 
As ravi said, the scope of your UOW is always the connection. You can 'guess' that from the connection handle being the argument to MQCMIT/MQBACK. Be aware that, if you put or get messages with MQ?MO_SYNCPOINT and don't issue a commit or rollback, MQSeries will implicitly commit if your process ends normally. If your process abends (protection fault, OS rc!=0, etc.), MQ will backout. It is always and everywhere recommended to be explicit.
Hope that helps,
Stefan
_________________
Stefan Sievert
IBM Certified * MQSeries
[ This Message was edited by: StefanSievert on 2002-01-25 21:03 ] |
|
| Back to top |
|
|
| Ash |
| Posted: Mon Jan 28, 2002 4:24 am Post subject: |
|
|
Novice
Joined: 07 Jan 2002
Posts: 17
|
Thanks a lot guys for your answers.
Stefan,
You hit the nail right on the head.
The idea that doing a commit from one application would impact the other unit of works is what was worrying me and you have cleared my doubts.
Cheers,
Ash |
|
| Back to top |
|
|
| dcipher18 |
| Posted: Sun Mar 30, 2003 7:18 am Post subject: |
|
|
Novice
Joined: 05 Sep 2002
Posts: 11
Location: Chicago
|
I've read through your discussion and I have a question. Do your comments about the scope of the unit of work being the connection apply to the Java MQSeries client classes also. I presume that it does, and as Stefan says, it wouldn't make much sense if the scope was anything more than that connection, but I haven't seen any documentation relating to Java that says this explicitly. In Java, the commit call is a method of the queue manager object. It makes sense to me that the queue manager object maintains a connection handle and behind the scenes either commits or backs-out of all operations within that unit of work (with the scope being the connection handle).
I would still like to be more definate that this is in fact what goes on. Can anyone confirm this for me?
Thanks in advance
Eddie |
|
| Back to top |
|
|
| emiranda |
| Posted: Mon Mar 31, 2003 4:45 am Post subject: |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
Since Feb 28 is available a new feature of MQ Client, called WebSphere MQ Extended Transactional Client, which supports extended architecture (XA) transaction management in conjunction with an external syncpoint coordinator, in both Java Messaging Service (JMS) and C clients. Take a look at http://www-3.ibm.com/software/integration/wmq/transclient.html
_________________
Warm Regards,
EM |
|
| Back to top |
|
|
|
|
