5:52 a.m.
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).
5:53 a.m.
New subject: javax.transaction.xa.Xid
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).
5:57 a.m.
New subject: javax.transaction.xa.Xid
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
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
6:12 a.m.
New subject: javax.transaction.xa.Xid
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).
4824
days inactive
4824
days old
infinispan-dev@lists.jboss.org
3 comments
3 participants
participants (3)
-
Jonathan Halliday -
Manik Surtani -
Mircea Markus