[infinispan-dev] XAResource.isSameRM

[Mircea Markus]

On 6 Jan 2011, at 14:45, Jonathan Halliday wrote:

> On 01/06/2011 02:29 PM, Mircea Markus wrote:
> 
>> At the moment the *only way to transactionally* access a
>> node is by collocating the client and the server in the same
>> VM.
> 
> So the scope of the transaction is limited to data residing in that local node? What if I want a single transaction to span the local node and data in a remote node?
that's possible. It's just that you have to always interact with the local node that will acquire remote locks remotely on behalf of your transaction.
> Or what about where the data is all in the local node, but the node has a remote replica for fault tolerance?
The same scenario as above. Attached is a diagram depicting how ISPN handle tx under the hood(TM, User and NodeA are in the same VM)
> 
>> client and the node in same VM ... if the node crashes you can
>> safely assume that the client is crashed as well.
> 
> No, you can't. The client has persistent state on disk courtesy of the transaction manager log and will restore that after the crash. It's not volatile. The transaction updates may also have spanned out to other systems.

Wouldn't that be solved if the XID for the heuristic rollback transaction is returned by the RM(ISPN cluster) in the XAResource.recover method? 
Might be wrong but I see two possibilities:
a) node goes down before TM issued prepare
     - when TM resurrects and calls XAResource.recover it receives the given XID, realises that there's an heuristic decision (because it didn't call prepare) and take some action (rollbacks other participants, notify sys admin?). 
b) node goes down after TM issues prepare
     - when TM issues a commit it receives an XAException (perhaps XA_HEURRB)  and again it is aware of the heuristic outcome 
> Your model only works for infinispan in single node volatile store configurations. As soon as you cluster or spill to persistent backing store you are in trouble. That's better than nothing, but pretty limiting for users. I'm not really clear what advantage it has over implementing Synchronization rather than XAResource. Why are you bothering with 2PC if you're not going to actually provide ACID semantics?
The plan is to support ACID semantics.
> 
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110106/049bf1ec/attachment-0002.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.pdf
Type: application/pdf
Size: 56622 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110106/049bf1ec/attachment-0001.pdf 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110106/049bf1ec/attachment-0003.html