| Author |
Message
|
| mvic |
 Posted: Tue Jul 11, 2006 5:26 am Post subject: |
 |
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Vitor wrote: |
| As indicated above, if you're using external resources and wish to coordinate the commit with those resources using a non-binding connection then you need the ETC. |
Unless Daniel has an external transaction monitor, he'll need to use MQBEGIN. To use MQBEGIN, the program must be running on the server. The ETC does not allow you to call MQBEGIN from a client. |
|
| Back to top |
|
 |
| Daniel Shaya |
| Posted: Tue Jul 11, 2006 5:27 am Post subject: |
|
|
Novice
Joined: 10 Jul 2006
Posts: 11
|
MVIC,
I am slighlty confused again, I thought we said that if the queueManager was not running on my box I had to use the ETC. I would much rather use the begin() close() backout() methods on the MQQueueManager but I thought we established that this was not possible if the queueManager was not on the same box.
By the way I am not running an external transaction manager.
Please explain.
Thanks for bearing with me on this one. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Jul 11, 2006 5:50 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Daniel Shaya wrote: |
| Please explain. |
If you need to include MQGET, MQPUT and database updates atomically within the same UOW, you need to use either
* MQBEGIN in an app on the server, or
* an external transaction monitor, in which case you can run the app remotely (but you'll need the ETC) or, alternatively, on the server.
See the following, entitled "What is an extended transactional client?", in the Clients manual: http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzaf.doc/intexttrancl.htm |
|
| Back to top |
|
|
| Daniel Shaya |
| Posted: Tue Jul 11, 2006 5:59 am Post subject: |
|
|
Novice
Joined: 10 Jul 2006
Posts: 11
|
I think my best bet is get an MQQueueManager installed on my client box, then I can use the built in transaction methods on the API.
I hope getting this 'proxy' queueManager installed is not too difficult.
Thanks again
Daniel |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 11, 2006 6:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Daniel Shaya wrote: |
I think my best bet is get an MQQueueManager installed on my client box, then I can use the built in transaction methods on the API.
I hope getting this 'proxy' queueManager installed is not too difficult.
Thanks again
Daniel |
Pedantically, if you get a queue manager installed on your client box it's not a client in mq terms but a server with all the licensing implications that carries with it. It's not a "proxy" anything, but a full queue manager. You just need to follow the installation instructions for your platform.
Mind you, as jefflowery pointed out a few posts back, the license fee is the same (which I was unaware of).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 11, 2006 2:44 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you need to do XA, then you should reexamine your application deployment environment.
It's entirely reasonable to have a qmgr for your particular application, on a dedicated machine. Assuming your application has sufficient load to justify dedicated hardware. If it doesn't have sufficient load or isolation requirements, then you obviously install it on a machine that already has a queue manager - and possibly add a database client to that machine.
Also, there is some qmgr configuration that has to be done to enable XA for a particular database.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 11, 2006 4:53 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
2 separate single phase commits are usualy adequate.
A. MQGET the message under syncpoint
B. Insert the message into the DB
C. Commit the DB Insert
D. Commit the MQGET
You have a tiny vulnerability between C and D. Do nothing else inbetween. Do C and D as fast as possible. However, if C works but your app bombs or loses the connection to MQ before D completes succesfully, you are in doubt.
However, if you can live with that, if you can code for the possability of later picking up the same MQ message because you didn't get to complete the MQ commit (and the message rolled back to the queue), then you can avoid the ETC, or the local QM, the MQBegin, etc....
Otherwise, you truly have a 2 phase requirement, and the business must pay for the ETC licenses or the full QM licenses everywhere your code runs
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Daniel Shaya |
| Posted: Wed Jul 12, 2006 12:35 am Post subject: |
|
|
Novice
Joined: 10 Jul 2006
Posts: 11
|
Thanks for your advice.
2 Questions:
1) How exactly do I use synchpoint (if possible code example) when doing a get.
2) Will this work in my case, where I want to take many items off a queue and do a batch commit on those objects all in one transaction. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 12, 2006 12:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Daniel Shaya wrote: |
How exactly do I use synchpoint (if possible code example) when doing a get.
|
I think I've already pointed you at the SYNCPOINT get option (though it seems like so long ago now.....  )
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Daniel Shaya |
| Posted: Wed Jul 12, 2006 1:12 am Post subject: |
|
|
Novice
Joined: 10 Jul 2006
Posts: 11
|
Sorry,
I am clearly missing something here but:
I thought we established that syncpoint can only be used if the queue is running onthe same box.
What is the difference between using syncpoint with commits etc and using the begin(), commit(), transactions.
Please explain. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 12, 2006 1:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
It's the same get option - it's what it does, and the surrounding program design, that differs. Like do you use begin / commit as well, are you using an external API, etc, etc. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Jul 12, 2006 2:18 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jul 12, 2006 2:36 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You can use MQGMO_SYNCPOINT from a MQ client connection to a remote queue manager.
You don't need the ETC except for true 2 phase commit (ie database and message in one unit of work).
MQGMO_SYNCPOINT just defers the actual message deletion until the MQCMIT is issued later. So if your transaction fails, the message will be made available again.
HOWEVER, you must look at the MQMD.Backout count field (after your MQGET) to ensure you don't loop indefinitely reprocessing a message (and failing).
If the backout count is more than a value (eg 3) then PUT the "poison" message to another queue and commit. |
|
| Back to top |
|
|
| Daniel Shaya |
| Posted: Wed Jul 12, 2006 4:58 am Post subject: |
|
|
Novice
Joined: 10 Jul 2006
Posts: 11
|
Thanks
Do you commit by calling commit() on the queueManager? I'm using the Java API on MQSeries. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 12, 2006 5:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Are you reading any of the links people are suggesting? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
