<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 6 Jan 2011, at 14:45, Jonathan Halliday wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 01/06/2011 02:29 PM, Mircea Markus wrote:<br><br><blockquote type="cite">At the moment the *only way to transactionally* access a<br></blockquote><blockquote type="cite">node is by collocating the client and the server in the same<br></blockquote><blockquote type="cite">VM.<br></blockquote><br>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?</div></blockquote>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.<br><blockquote type="cite"><div> Or what about where the data is all in the local node, but the node has a remote replica for fault tolerance?<br></div></blockquote>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)<br><blockquote type="cite"><div><br><blockquote type="cite">client and the node in same VM ... if the node crashes you can<br></blockquote><blockquote type="cite">safely assume that the client is crashed as well.<br></blockquote><br>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.</div></blockquote></div><div>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? </div><div>Might be wrong but I see two possibilities:</div><div>a) node goes down before TM issued prepare</div><div> - 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?). </div><div>b) node goes down after TM issues prepare</div><div> - when TM issues a commit it receives an XAException (perhaps <span class="Apple-style-span" style="font-family: 'Times New Roman'; font-size: 10px; ">XA_HEURRB)</span> and again it is aware of the heuristic outcome </div><div><blockquote type="cite"><div> 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?</div></blockquote>The plan is to support ACID semantics.<br><blockquote type="cite"><div><br>Jonathan.<br><br>-- <br>------------------------------------------------------------<br>Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.<br>Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland)<br></div></blockquote></div></body></html>