| Author |
Message
|
| speediii |
 Posted: Tue Apr 11, 2006 2:22 am Post subject: What defines a "Unit of Work" with MQ/Java syncpoi |
 |
|
Novice
Joined: 11 Apr 2006
Posts: 19
|
This is maybe a stupid question but I've done a lot of reading and failed to find an answer to my question (really not so obvious from the documentation)
I have written a simple Java broker where I define Source & Target MQ Adapters in a configuration file - I then have a Controller Thread reading the configuration and moving messages from one source to one-to-many Targets.
I need to syncpoint the one GET MQ message operation together with the many MQ PUT operations. Sadly I thought that an MQ "unit of work" was defined by all put/get operations performed within the same Thread (obviously with MQxMO_SYNCPOINT set on each get/put). But it appears that I have to use the same MQQueueManager java Object for all the Get & Put operations? Which is tricky because my Source/Target java classes have their own MQQueueManager Object and Open the queue for Get or Put operations....
This wasn't that obvious as coding I'd done before with the Candlenet Roma Java libraries (that sit over MQ) had syncpoint transactions that were Thread based. This caused it's own problems but I understood that this was the way MQ was working.
Can someone please confirm that an MQ "unit of work" is all operations performed on the SAME MQQueueManager object (with MQxMO_SYNCPOINT used in the get & put options)?
If so, I will now have to restructure my Java code to define a common MQQueueManager object used by both the Source and one-to-many target adapters in each control flow....to do the MQQueueManager.commit()
Many thanks
Lee |
|
| Back to top |
|
 |
| mvic |
| Posted: Tue Apr 11, 2006 2:31 am Post subject: Re: What defines a "Unit of Work" with MQ/Java syn |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| speediii wrote: |
| Can someone please confirm that an MQ "unit of work" is all operations performed on the SAME MQQueueManager object (with MQxMO_SYNCPOINT used in the get & put options)? |
Correct. But you also said
| Quote: |
| Sadly I thought that an MQ "unit of work" was defined by all put/get operations performed within the same Thread |
So is it really a problem to have a separate MQQueueManager on each thread? If you want separate units of work running independently on each thread, then the best way to achieve this is probably to have an MQQueueManager per thread. |
|
| Back to top |
|
|
| speediii |
| Posted: Tue Apr 11, 2006 2:40 am Post subject: |
|
|
Novice
Joined: 11 Apr 2006
Posts: 19
|
Thanks for the response - I was really looking for confirmation that this was the way it was working.
I want all operations per Thread to be in one "unit of work". This means I can only have one MQQueueManager defined per thread used by all Source & Target Adapters - tricky, because I'd done my object design contrary to this.
I will define one MQQueueManager object per Thread now and it should work I guess. I had looked at some open source code (OpenAdapter + Proteus amoungst others and these don't seem to work this way, hence I've gone down this path.
the MQ documentation talks about "unit of work", but it wasn't obvious to me that:
"a 'unit of work' is all get/put operations with SYNCPOINT in the options performed on the same, single MQQueueManager object"
This is important when designing more complex broker like Java code.
Thanks |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Apr 11, 2006 3:09 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| speediii wrote: |
| the MQ documentation talks about "unit of work", but it wasn't obvious... |
I see what you mean. In actual fact the MQ Java classes call the MQI to do the real work with the queue manager. The scope of a UOW in the MQI is per-hConn. The object in the Java classes that encapsulates the hConn is the MQQueueManager.
(If you had been using JMS, the object that encapsulates the hConn is the Session. However the transactional scoping in JMS is very clearly bound to the Session, leaving no room for doubt).
Sorry you had a problem with this. The most relevant information I could find in a quick browse through the Using Java manual is http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzaw.doc/csqzaw1430.htm |
|
| Back to top |
|
|
| speediii |
| Posted: Tue Apr 11, 2006 11:30 pm Post subject: |
|
|
Novice
Joined: 11 Apr 2006
Posts: 19
|
| Having read the link you posted it now makes perfect sense. The previous wrapper classes I was using to code MQ connectors (The old Candlenet Roma classes) sat over the C libraries, hence the connections were Thread based, not Thread safe (synchronised). |
|
| Back to top |
|
|
|
|
