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