Re: [infinispan-dev] javax.transaction.xa.Xid

You'll need to store the content, not the Object. The interface has getters to extract the field values which are primitive types and thus easy to store. You'll need your own impl of the interface if you need to recreate internally. JBossTS does not care what it receives, as long as it implements the Xid interface. It won't necessarily give you back your own impl when calling your methods though.

If you're writing your own impl the most important bit oddly enough is toString(). We have endless hassle from systems that print Xids binary value in different forms, making correlation of the TM and RM logs rather hairy. Try not to invent yet another format please :-)

Jonathan. On 03/17/2011 10:26 AM, Mircea Markus wrote: > Hi Jonathan, > > We need to serialize the javax.transaction.xa.Xid received from TM in order to back up information on other nodes. Xid is not serializable so we need to use our internal Xid implementation in order to be able to de-serialize it. > This also means that XAResource.recover returns Xid instances that are of type org.infinispan.tx.Xid, with its own implementation of equals and hashcode, but with exactly the same state as the org.custom.tm.Xid. > Would JBossTM expect XAResource.recover to return Xids of a different java.lang.Class? What's your take in general on this problem? > > Cheers, > Mircea -- Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).