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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Mircea Markus
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
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Mircea Markus

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Mircea Markus

On 17 Mar 2011, at 10:52, Mircea Markus wrote:

>
> 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()
I ment com.arjuna.ats.jta.xa.XID.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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Manik Surtani
In reply to this post by Mircea Markus

On 17 Mar 2011, at 10:52, Mircea Markus wrote:

> Pluggable .toString() - can't believe I've just said that!!! :-)
>


What an awesome concept!  :-)  Not.
--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org



_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Jonathan Halliday

On 03/17/2011 10:57 AM, Manik Surtani wrote:
>
> On 17 Mar 2011, at 10:52, Mircea Markus wrote:
>
>> Pluggable .toString() - can't believe I've just said that!!! :-)

lol. JBossTS does not make it pluggable, but does use an implementation
specific rendering for Xids it created itself and thus knows how to
decode the bytes for. Where the Xid was generated externally and passed
in we just render the binary in some reasonable way. Note that the
general case is that the TM is creating the Xids and the RM only working
with them.  If you're going for full compatibility you can copy the TS
code that knows how to handle 'native' JBossTS Xids (risky, as we change
for structure from from time to time), or at minimum just use the same
generic binary rendering that we do. In most non-recovery cases you'll
have an Xid Object created by JBossTS anyhow and it will handle the
toString itself.

Another possibility is to have your code test for Serializability of Xid
and serialize it if possible or use its own path if not. That way you
probably have native toString behaviour at recovery time too as the
JBossTS impl is Serializable.  Does make your code a bit more convoluted
though.

Jonathan.

--
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev