Re: [infinispan-dev] XAResource.isSameRM
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)
Attachments:
- attachment.html (text/html — 136 bytes)
- PastedGraphic-2.pdf (application/pdf — 55.3 KB)
- attachment.html (text/html — 3.4 KB)