<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 18 Mar 2011, at 12:47, Manik Surtani wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 18 Mar 2011, at 12:41, Mircea Markus wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div bgcolor="#FFFFFF"><div><br><br><br></div><div><br>On 18 Mar 2011, at 12:32, Manik Surtani <<a href="mailto:manik@jboss.org">manik@jboss.org</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><br><div><div>On 18 Mar 2011, at 12:13, Mircea Markus wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi,<br><br>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.<br>E.g. step >= 3.3 : <a href="http://community.jboss.org/servlet/JiveServlet/showImage/102-16552-14-11811/3_non_originator_failure.png"></a><a href="http://community.jboss.org/servlet/JiveServlet/showImage/102-16552-14-11811/3_non_originator_failure.png">http://community.jboss.org/servlet/JiveServlet/showImage/102-16552-14-11811/3_non_originator_failure.png</a><br><br>Here is what I have in mind:<br><br>Expose (JMX) two operations:<br><br> //all the params together fully describe a xid.<br> replayTx(byte[] txBranch, byte[] txId, int formatId); <br> forceRollbackTx(byte[] txBranch, byte[] txId, int formatId);<font class="Apple-style-span"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><br><div>You expect a sysadmin to type a byte array into a JMX console? :-) You might get death threats from sysadmins... </div></div></div></blockquote>I imagine untraceble threats, right?<div>String then...<br></div></div></blockquote><div><br></div><div>Can an XID be mapped to a String (and vice versa) reliably, in a TransactionManager-independent manner?</div></div></div></blockquote>Xid can be reliably mapped to (<span class="Apple-style-span" style="color: rgb(84, 0, 0); ">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.</span><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br><blockquote type="cite"><div bgcolor="#FFFFFF"><div><blockquote type="cite"><div><div><br><blockquote type="cite"><div>Here is how these two ops would work:<br>A. replayTx <br> 1. the node has locally the PrepareCommand associated with that XID<br><span class="Apple-tab-span" style="white-space:pre"> </span>- re-issues a prepare: TransactionXAResource.prepare<br><span class="Apple-tab-span" style="white-space:pre"> </span>- if successful re-issues a commit: TransactionXAResource.commit<br> -if failure happens at any step the user is informed and she/he can re-do the JMX call<br><span class="Apple-tab-span" style="white-space:pre"> </span>- if success the recovery information is removed from the cluster (async)<br> 2. the node doesn't have the PrepareCommand associated with that XID<br><span class="Apple-tab-span" style="white-space:pre"> </span>- broadcast ReplayTxCommand (Xid)<br> - when a node receives ReplayTxCommand<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>- if doesn't have a PreparedCommand associated with the Xid ignores it<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>- if has a PreparedCommand...<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>- is it the first in the view that has it [1]? <br></div></blockquote><div><br></div><div>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?</div></div></div></blockquote>No, [1] explains it<br></div></div></blockquote><div><br></div><div>Ok, as long as this is deterministic.</div></div></div></blockquote>It is, see [1] :-)<br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br><blockquote type="cite"><div bgcolor="#FFFFFF"><div><blockquote type="cite"><div><div><br><blockquote type="cite"><div><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>- 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<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>- no. Ignores it.<br><span class="Apple-tab-span" style="white-space:pre"> </span>- if success the recovery information is removed from the cluster (async)<br>B.rollbackTx<br> - node broadcasts RollbackCommand<br> - each node that has the PrepareCommand forces a rollback<br> - each node that doesn't have the PreparedCommand ignores it<br> - if success the recovery information is removed from the cluster (async)<br><br>Cheers,<br>Mircea<br><br>[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. <br>[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). <br><br><br><br><br><br>_______________________________________________<br>infinispan-dev mailing list<br><a href="mailto:infinispan-dev@lists.jboss.org"></a><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br></div></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><div>--</div><div>Manik Surtani</div><div><a href="mailto:manik@jboss.org"></a><a href="mailto:manik@jboss.org">manik@jboss.org</a></div><div><a href="http://twitter.com/maniksurtani"></a><a href="http://twitter.com/maniksurtani">twitter.com/maniksurtani</a></div><div><br></div><div>Lead, Infinispan</div><div><a href="http://www.infinispan.org/"></a><a href="http://www.infinispan.org/">http://www.infinispan.org</a></div><div><br></div></div></span><br class="Apple-interchange-newline">
</div>
<br></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>infinispan-dev mailing list</span><br><span><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></span></div></blockquote></div></div>_______________________________________________<br>infinispan-dev mailing list<br><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><div>--</div><div>Manik Surtani</div><div><a href="mailto:manik@jboss.org">manik@jboss.org</a></div><div><a href="http://twitter.com/maniksurtani">twitter.com/maniksurtani</a></div><div><br></div><div>Lead, Infinispan</div><div><a href="http://www.infinispan.org/">http://www.infinispan.org</a></div><div><br></div></div></span><br class="Apple-interchange-newline">
</div>
<br></div>_______________________________________________<br>infinispan-dev mailing list<br><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/infinispan-dev</blockquote></div><br></body></html>