On 16 Dec 2010, at 10:51, Manik Surtani wrote: > Ah right, I get your point. So there are 2 cases: > > 1) When the failing resource manager is *not* an Infinispan node: returning a list of prepared or heuristically committed Xids is trivial for Infinispan since (a) we maintain an internal list of prepared txs, and (b) we don't heuristically commit. (Mircea can confirm this) > > 2) When the failing resource manager is an Infinispan node (failed and restarted, for example), and the TM calls recover on this node. In this case, recover will return a null, which, correctly, will lead the TM to believe that there are no prepared or heuristically committed txs on this node - which is correct, since the node would have been reset to the last-known stable state prior to the failure. Does recover return a list of Xids for active (inflight) resources? Since recover can be called at any time, it's possible that the Xids may/can point to resources that have not failed. The thing to remember is that the transaction manager may fail independently of the resource manager. Do you think that the implementation you've got at the moment will be fine in that circumstance?

On 16 Dec 2010, at 10:51, Manik Surtani wrote: > Ah right, I get your point. So there are 2 cases: > > 1) When the failing resource manager is *not* an Infinispan node: returning a list of prepared or heuristically committed Xids is trivial for Infinispan since (a) we maintain an internal list of prepared txs, and (b) we don't heuristically commit. (Mircea can confirm this) re: (b) - we do heuristically rollback: if a node where a tx originated crashes the changes/locks held on behalf of that transaction on other nodes are rollback heuristically. Right now we don't announce the TM about this heuristic decision. One way of handling this might be by remembering the transaction on one of the nodes where we roll it back and then inform the TM about it through XAResource.recover

> > 2) When the failing resource manager is an Infinispan node (failed and restarted, for example), and the TM calls recover on this node. In this case, recover will return a null, which, correctly, will lead the TM to believe that there are no prepared or heuristically committed txs on this node - which is correct, since the node would have been reset to the last-known stable state prior to the failure. Not sure this is entirely correct, as we do make an heuristic decision to rollback the tx started on the failing node.

> > So what we have right now is the ability to deal with case (2). Case (1) should be implemented as well to be a "good participant" in a distributed transaction. > > Adding infinispan-dev in cc, as this would be of interest there. > > Cheers > Manik > > On 16 Dec 2010, at 10:36, Mark Little wrote: > >> So XAResource.recover and the XA protocol have well defined semantics for recovery. If you do a no-op and there are resources that need recovering, the transaction may still not be entirely ACID even though the transaction manager believes it to be the case. Unless you do the recovery for the nodes in the recover call and return a null list of Xids, your XAResource implementation is breaking the XA protocol. >> >> Mark. >> >> >> On 16 Dec 2010, at 10:31, Manik Surtani wrote: >> >>> >>> On 16 Dec 2010, at 10:23, Mark Little wrote: >>> >>>> So what happens when the recover method is invoked on the Infinispan XAResource implementation? I'm assuming it obeys the protocol if you're saying "we do support XA" ;-) >>> >>> Well, this is what I mean by "we don't support recover" right now. At the moment recover() is a no-op and we just log it, expecting manual intervention (node restart), but this should be automated (wipe in-memory state and rejoin the cluster). >>> >>> >>>> >>>> Mark. >>>> >>>> >>>> On 16 Dec 2010, at 10:18, Manik Surtani wrote: >>>> >>>>> Well, it hinges on how we implement recover. Recovery for Infinispan is, simply, restarting the node at fault and allow it to regain state from a neighbour. As opposed to more "traditional" impls of XA recovery, involving maintaining a tx log (fsync'd to disk). One may say then that we do support recovery, only that the tx log is maintained "in the cluster". >>>>> >>>>> On 16 Dec 2010, at 09:23, Mark Little wrote: >>>>> >>>>>> So we support a bit of XA then, i.e., not the recover operation? >>>>>> >>>>>> Mark. >>>>>> >>>>>> >>>>>> On 15 Dec 2010, at 17:29, Manik Surtani wrote: >>>>>> >>>>>>> >>>>>>> On 15 Dec 2010, at 17:24, Bill Burke wrote: >>>>>>> >>>>>>>>> >>>>>>>>> eh - you would have the same problems with Infinispan as with Hypersonic explaining users that if you want ACID database access you need >>>>>>>>> to use a real database and not a glorified hashmap ;) >>>>>>>>> >>>>>>>> >>>>>>>> sounds like a good feature request, to support XA/recovery. If you're gonna use Infinispan for a data grid, prolly a lot of people gonna want this. >>>>>>> >>>>>>> We do support XA. Not recovery though - since it is a p2p grid. ("Recovering" would simply involve the node wiping in-memory state, and re-joining the cluster since non-corrupted copies of its data exists elsewhere in the cluster). >>>>>>> >>>>>>> Cheers >>>>>>> Manik >>>>>>> >>>>>>> -- >>>>>>> Manik Surtani >>>>>>> manik(a)jboss.org >>>>>>> twitter.com/maniksurtani >>>>>>> >>>>>>> Lead, Infinispan >>>>>>> http://www.infinispan.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --- >>>>>> Mark Little >>>>>> mlittle(a)redhat.com >>>>>> >>>>>> JBoss, by Red Hat >>>>>> 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). >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Manik Surtani >>>>> manik(a)jboss.org >>>>> twitter.com/maniksurtani >>>>> >>>>> Lead, Infinispan >>>>> http://www.infinispan.org >>>>> >>>>> >>>>> >>>>> >>>> >>>> --- >>>> Mark Little >>>> mlittle(a)redhat.com >>>> >>>> JBoss, by Red Hat >>>> 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). >>>> >>>> >>>> >>>> >>> >>> -- >>> Manik Surtani >>> manik(a)jboss.org >>> twitter.com/maniksurtani >>> >>> Lead, Infinispan >>> http://www.infinispan.org >>> >>> >>> >> >> --- >> Mark Little >> mlittle(a)redhat.com >> >> JBoss, by Red Hat >> 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). >> >> >> >> > > -- > Manik Surtani > manik(a)jboss.org > twitter.com/maniksurtani > > Lead, Infinispan > http://www.infinispan.org > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev