[infinispan-dev] SysAdmin operations for recovering transactions

[Mircea Markus]

On 18 Mar 2011, at 12:47, Manik Surtani wrote:

> 
> On 18 Mar 2011, at 12:41, Mircea Markus wrote:
> 
>> 
>> 
>> 
>> 
>> On 18 Mar 2011, at 12:32, Manik Surtani <manik at jboss.org> wrote:
>> 
>>> 
>>> On 18 Mar 2011, at 12:13, Mircea Markus wrote:
>>> 
>>>> Hi,
>>>> 
>>>> It's about the stage where TM's recovery  process finds a in-doubt transaction and notifies the sys admin about it: what hooks does ISPN provide to the sys admin in order to "fix" the tx.
>>>> E.g. step >= 3.3 : http://community.jboss.org/servlet/JiveServlet/showImage/102-16552-14-11811/3_non_originator_failure.png
>>>> 
>>>> Here is what I have in mind:
>>>> 
>>>> Expose (JMX) two operations:
>>>> 
>>>>   //all the params together fully describe a xid.
>>>>   replayTx(byte[] txBranch, byte[] txId, int formatId); 
>>>>   forceRollbackTx(byte[] txBranch, byte[] txId, int formatId);
>>> 
>>> You expect a sysadmin to type a byte array into a JMX console?  :-)  You might get death threats from sysadmins... 
>> I imagine untraceble threats, right?
>> String then...
> 
> Can an XID be mapped to a String (and vice versa) reliably, in a TransactionManager-independent manner?
Xid can be reliably mapped to (byte[] txBranch, byte[] txId, int formatId). The only part left is converting a String (as received from JMX operation) to the corresponding  byte[]. Seems doable.
> 
> 
>>> 
>>>> Here is how these two ops would work:
>>>> A. replayTx 
>>>>    1. the node has locally the PrepareCommand associated with that XID
>>>> 	- re-issues a prepare: TransactionXAResource.prepare
>>>> 	- if successful re-issues a commit: TransactionXAResource.commit
>>>>        -if failure happens at any step the user is informed and she/he can re-do the JMX call
>>>> 	- if success the recovery information is removed from the cluster (async)
>>>>    2. the node doesn't have the PrepareCommand associated with that XID
>>>> 	- broadcast ReplayTxCommand (Xid)
>>>>        - when a node receives ReplayTxCommand
>>>> 		- if doesn't have a PreparedCommand associated with the Xid ignores it
>>>> 		- if has a PreparedCommand...
>>>> 			- is it the first in the view that has it [1]? 
>>> 
>>> How does a node know the answer to this question?  Is the list of nodes that holds the prepare replay info stored on the PrepareCommand?
>> No, [1] explains it
> 
> Ok, as long as this is deterministic.
It is, see [1] :-)
> 
>>> 
>>>> 				- yes. Execute A.1then returns result to node that broadcasted ReplayTxCommand. This is guaranteed to happen on at most[2] one node in the cluster
>>>> 				- no. Ignores it.
>>>> 	- if success the recovery information is removed from the cluster (async)
>>>> B.rollbackTx
>>>>   - node broadcasts RollbackCommand
>>>>   - each node that has the PrepareCommand forces a rollback
>>>>   - each node that doesn't have the PreparedCommand ignores it
>>>>   - if success the recovery information is removed from the cluster (async)
>>>> 
>>>> Cheers,
>>>> Mircea
>>>> 
>>>> [1] this is determined by building the set of nodes on which tx spreads, based on tx's state. Then determine the first in the view. 
>>>> [2] it is possible not to happen on any node as the PrepareCommand might had been removed from all nodes in between (node failures, expiration from the recovery cache). 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> 
>>> --
>>> Manik Surtani
>>> manik at jboss.org
>>> twitter.com/maniksurtani
>>> 
>>> Lead, Infinispan
>>> http://www.infinispan.org
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
> 
> Lead, Infinispan
> http://www.infinispan.org
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110318/ab5bfb3f/attachment-0001.html