Re: [infinispan-dev] Can we replace Hypersonic with...

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Can we replace Hypersonic with...

Manik Surtani
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.

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
>>>>>> [hidden email]
>>>>>> twitter.com/maniksurtani
>>>>>>
>>>>>> Lead, Infinispan
>>>>>> http://www.infinispan.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---
>>>>> Mark Little
>>>>> [hidden email]
>>>>>
>>>>> 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
>>>> [hidden email]
>>>> twitter.com/maniksurtani
>>>>
>>>> Lead, Infinispan
>>>> http://www.infinispan.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---
>>> Mark Little
>>> [hidden email]
>>>
>>> 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
>> [hidden email]
>> twitter.com/maniksurtani
>>
>> Lead, Infinispan
>> http://www.infinispan.org
>>
>>
>>
>
> ---
> Mark Little
> [hidden email]
>
> 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
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Can we replace Hypersonic with...

Mark Little

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?

Mark


>
> 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
>>>>>>> [hidden email]
>>>>>>> twitter.com/maniksurtani
>>>>>>>
>>>>>>> Lead, Infinispan
>>>>>>> http://www.infinispan.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---
>>>>>> Mark Little
>>>>>> [hidden email]
>>>>>>
>>>>>> 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
>>>>> [hidden email]
>>>>> twitter.com/maniksurtani
>>>>>
>>>>> Lead, Infinispan
>>>>> http://www.infinispan.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---
>>>> Mark Little
>>>> [hidden email]
>>>>
>>>> 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
>>> [hidden email]
>>> twitter.com/maniksurtani
>>>
>>> Lead, Infinispan
>>> http://www.infinispan.org
>>>
>>>
>>>
>>
>> ---
>> Mark Little
>> [hidden email]
>>
>> 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
> [hidden email]
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>

---
Mark Little
[hidden email]

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).





_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Can we replace Hypersonic with...

Manik Surtani

On 16 Dec 2010, at 14:19, Mark Little wrote:

>
> 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?

Yes, this is case (1), as I had outlined earlier.  We don't deal with this at the moment and you're right that we should.  There is an open JIRA for this.

Cheers
Manik
--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Can we replace Hypersonic with...

Mircea Markus
In reply to this post by Manik Surtani

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
>>>>>>> [hidden email]
>>>>>>> twitter.com/maniksurtani
>>>>>>>
>>>>>>> Lead, Infinispan
>>>>>>> http://www.infinispan.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---
>>>>>> Mark Little
>>>>>> [hidden email]
>>>>>>
>>>>>> 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
>>>>> [hidden email]
>>>>> twitter.com/maniksurtani
>>>>>
>>>>> Lead, Infinispan
>>>>> http://www.infinispan.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---
>>>> Mark Little
>>>> [hidden email]
>>>>
>>>> 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
>>> [hidden email]
>>> twitter.com/maniksurtani
>>>
>>> Lead, Infinispan
>>> http://www.infinispan.org
>>>
>>>
>>>
>>
>> ---
>> Mark Little
>> [hidden email]
>>
>> 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
> [hidden email]
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Can we replace Hypersonic with...

Mark Little

On 5 Jan 2011, at 10:53, Mircea Markus wrote:

>
> 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

Bad, bad, bad, bad, bad. Oh, and it's bad. :-)

>>
>> 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.

Yes, that's bad too ;-)

Mark.


>>
>> 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
>>>>>>>> [hidden email]
>>>>>>>> twitter.com/maniksurtani
>>>>>>>>
>>>>>>>> Lead, Infinispan
>>>>>>>> http://www.infinispan.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> Mark Little
>>>>>>> [hidden email]
>>>>>>>
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> twitter.com/maniksurtani
>>>>>>
>>>>>> Lead, Infinispan
>>>>>> http://www.infinispan.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---
>>>>> Mark Little
>>>>> [hidden email]
>>>>>
>>>>> 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
>>>> [hidden email]
>>>> twitter.com/maniksurtani
>>>>
>>>> Lead, Infinispan
>>>> http://www.infinispan.org
>>>>
>>>>
>>>>
>>>
>>> ---
>>> Mark Little
>>> [hidden email]
>>>
>>> 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
>> [hidden email]
>> twitter.com/maniksurtani
>>
>> Lead, Infinispan
>> http://www.infinispan.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

---
Mark Little
[hidden email]

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).





_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Can we replace Hypersonic with...

Manik Surtani

On 7 Jan 2011, at 11:44, Mark Little wrote:

>
> On 5 Jan 2011, at 10:53, Mircea Markus wrote:
>
>>
>> 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
>
> Bad, bad, bad, bad, bad. Oh, and it's bad. :-)
>
>>>
>>> 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.
>
> Yes, that's bad too ;-)

Yup - this is what we're realising in the parallel discussion with Jonathan.  

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...