On 17 Mar 2011, at 10:33, Jonathan Halliday wrote:

> 
> 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.
good, that's what I expected.
> 
> 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 :-)
What I can do is use the same .toString from JBossTM: can you please confirm 
this is the one: com.arjuna.ats.jta.xa.toString()
The problem is still there for other TMs though, so at one point we might want 
to do this pluggable. 
Pluggable .toString() - can't believe I've just said that!!! :-) 
> 
> 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).


_______________________________________________
infinispan-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Reply via email to