| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Error when using XAResource.recover() with MQ5.2 on Linux |
« View previous topic :: View next topic » |
| Author |
Message
|
| dorrats |
 Posted: Mon Jan 20, 2003 4:46 pm Post subject: Error when using XAResource.recover() with MQ5.2 on Linux |
 |
|
Newbie
Joined: 19 Jan 2003
Posts: 4
Location: Melbourne Australia
|
I have a problem attempting to recover a distributed transaction on
MQSeries 5.2 on Linux using the JMS 5.22 library and the XA interface.
When I call the XAResource.recover() method I get an XAException thrown
with the error -5. I am not connecting in Client mode.
The code I use is:
XAResource l_xaRes m_XAqSess.getXAResource();
Xid [] l_xidArray = l_xaRes.recover(l_xaRes.TMNOFLAGS);
And the exception thrown is
javax.transaction.xa.XAException: XA operation failed, see errorCode
at com.ibm.mq.MQXAResource.recover(MQXAResource.java:660)
(errorCode=-5)
The same code works fine with SonicMQ
We are running Red Hat 7.2 Linux. It is the first time we have tried to do this on MQSeries.
Has anyone tried this before or had similar problems?
Simon Dorrat |
|
| Back to top |
|
 |
| kingdon |
| Posted: Mon Jan 20, 2003 11:50 pm Post subject: |
|
|
Acolyte
Joined: 14 Jan 2002
Posts: 63
Location: UK
|
-5 is XAER_INVAL indicating an invalid argument. The first call to recover should pass in MQXAResource.TMSTARTRSCAN to indicate a new scan is required. Subsequent calls pass TMNOFLAGS to continue the current scan (loop until you get either a zero length array or an XAException). You don't need to use TMENDRSCAN if you loop until one of those end conditions (the scan is implicitly ended).
The mapping between the C XARECOVER method and the JTA version is poorly defined, so it's not surprising that you are seeing differences of interpretation between vendors.
Regards,
James. |
|
| Back to top |
|
|
| dorrats |
| Posted: Tue Jan 21, 2003 4:09 pm Post subject: |
|
|
Newbie
Joined: 19 Jan 2003
Posts: 4
Location: Melbourne Australia
|
Thanks James,
Supplying this flag does prevent the error. You mentioned the need to loop around the recover call. Does this mean that some providers will not pass back the Xids of all in-doubt transactions in the first recover call? With SonicMQ we only make one call and receive all appropriate Xids in the array in this call.
If I implement this looping, do you know the error code returned in the XAException when making the subsequent calls to recover (i..e the one I am supposed to trap and ignore?) Is it -5 again?
I can't find any documentation on how this interface is supposed to be used. Any tips or pointers to useful doco would be appreciated.
Simon |
|
| Back to top |
|
|
| dorrats |
| Posted: Tue Jan 21, 2003 10:29 pm Post subject: |
|
|
Newbie
Joined: 19 Jan 2003
Posts: 4
Location: Melbourne Australia
|
Further to my commens, I have actually found some info on the use of these flags in the JTA spec, though it is a bit vague. Any additional info welcome.
Thanks
Simon |
|
| Back to top |
|
|
| kingdon |
| Posted: Thu Jan 23, 2003 12:09 am Post subject: |
|
|
Acolyte
Joined: 14 Jan 2002
Posts: 63
Location: UK
|
Hi Simon,
It would be inappropriate for me to comment on other vendor's implementations, so I'll keep my reply generic.
Yes, some providers may require multiple calls to XAResource.recover() to return all in doubt xids. The XA spec defines the recover method in terms of a scan of the indbout xids using a cursor in order to cope with the possibility of a large number of in doubt transactions. Since the JTA mapping of the recover method has retained the flags for starting and ending the scan it is reasonable to suppose that some vendors will still expect multiple calls to the recover method in order to return a complete set of xids. This is the way the MQJMS implementation works. Note that a vendor could choose to return all xids in the first call, and this would still be a compliant implementation of the JTA spec'.
The problem arises because the JTA spec' didn't define the end condition. In the C version, you pass in a buffer to hold the xids and you know you've finished when the method returns less than a complete buffer full. Since the JTA version doesn't pass in a buffer (or a count of how many to retrieve) there is information lost in the mapping, hence the dual end-case behaviour we implemented.
As far as the error code in the XAException goes, yes I believe it will be -5 again (because the C routine implicitly closes the scan, and -5 is the return code for when you call recover(noflags) with no scan in progress).
For doc's, it's always useful to have the XA spec (ISBN 1 872630 24 3), since the JTA XAResource is mostly a straight forward mapping of XA.
Out of interest, why are you writing your own transaction coordinator?
Cheers,
James. |
|
| Back to top |
|
|
| dorrats |
| Posted: Tue Jan 28, 2003 7:48 pm Post subject: |
|
|
Newbie
Joined: 19 Jan 2003
Posts: 4
Location: Melbourne Australia
|
Thanks. I have now implemented both recovery patterns, with a runtime parameter directing the use of the multi-pass pattern for a XAResource implementation. This allows us to keep this recovery code generic to be used against any provider.
We have implemented our own (simplified) transaction manager in this and a few other cases as we run our middleware as CORBA components and don't run an OTS/JTS service. For the scenarios we used, it was thought to be easier and more flexible if we built it ourself. Of course it ended up to be not that easy, but once done we have been able to reuse the pattern a few times and it has paid off. Now we are attempting to use it for the first time with providers other than Oracle & SonicMQ and so are need to alter it slightly to be truly generic.
Thanks for your help.
Simon |
|
| 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
|
|
|
|
