<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<body link="#355491" alink="#4262a1" vlink="#355491" style="background: #e2e2e2; margin: 0; padding: 20px;">
<div>
<table cellpadding="0" bgcolor="#FFFFFF" border="0" cellspacing="0" style="border: 1px solid #dadada; margin-bottom: 30px; width: 100%; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tbody>
<tr>
<td>
<table border="0" cellpadding="0" cellspacing="0" bgcolor="#FFFFFF" style="border: solid 2px #ccc; background: #dadada; width: 100%; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tbody>
<tr>
<td bgcolor="#000000" valign="middle" height="58px" style="border-bottom: 1px solid #ccc; padding: 20px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -webkit-border-top-right-radius: 5px; -webkit-border-top-left-radius: 5px;">
<h1 style="color: #333333; font: bold 22px Arial, Helvetica, sans-serif; margin: 0; display: block !important;">
<!-- To have a header image/logo replace the name below with your img tag -->
<!-- Email clients will render the images when the message is read so any image -->
<!-- must be made available on a public server, so that all recipients can load the image. -->
<a href="http://community.jboss.org/index.jspa" style="text-decoration: none; color: #E1E1E1">JBoss Community</a></h1>
</td>
</tr>
<tr>
<td bgcolor="#FFFFFF" style="font: normal 12px Arial, Helvetica, sans-serif; color:#333333; padding: 20px; -moz-border-radius-bottomleft: 4px; -moz-border-radius-bottomright: 4px; -webkit-border-bottom-right-radius: 5px; -webkit-border-bottom-left-radius: 5px;"><h3 style="margin: 10px 0 5px; font-size: 17px; font-weight: normal;">
Re: Remoting Transport Transaction Inflow Design Discussion
</h3>
<span style="margin-bottom: 10px;">
created by <a href="http://community.jboss.org/people/tomjenkinson">Tom Jenkinson</a> in <i>JBoss Transactions Development</i> - <a href="http://community.jboss.org/message/642551#642551">View the full discussion</a>
</span>
<hr style="margin: 20px 0; border: none; background-color: #dadada; height: 1px;">
<div class="jive-rendered-content"><p><span>Just to confirm, the work for the transactions team side of this is now complete (as part of </span><a class="jive-link-external-small" href="https://issues.jboss.org/browse/JBTM-895" target="_blank">https://issues.jboss.org/browse/JBTM-895</a><span> and friends).</span></p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p><span>If you look at the example I have mentioned before (</span><a class="jive-link-external-small" href="https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_16/atsintegration/examples" target="_blank">https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_16/atsintegration/examples</a><span>) you will see how to achieve use the APIs we have exposed to perform this work within the transport tier.</span></p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>Of particular note are:</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>1. The transport is responsible for providing a *Serializable* XAResource that is able to proxy calls to remote servers.</p><p>2. Per transaction, only one link should be built to each subordinate, this is relatively trivial to ensure and the example provides a suggestion based on registering the resource after returning from the remote server where it is easy to detect an existing subordinate atomic action, note this applies the transaction as a global notion, i.e. do not create a subordinate transaction at the originating server even when the transaction flows back in to the server, the example shows one way how to guard against this.</p><p>3. The transport should have no need to persist additional details of transaction state if the pattern illustrated in the example is followed.</p><p>4. The transport is *not* responsible for maintaing a list of subordinate identifiers, that requirement is removed and this is managed by the transaction manager.</p><p>5. Per subordinate transaction a proxy synchronization and proxy xa resource will need to be registered.</p><p>6. As requested, the node names are able to be stored as Strings. The strings *must* be able to be String::getBytes()'d into a byte array no longer than 32 bytes.</p><p>7. After you return from a remote server you are suggested to check the state of the transaction returned in order to prevent needless propagation of a transaction that is set in rollback only state.</p><p>8. Transaction timeout is shown how to be handled in the example and as discussed in a different thread, it should not need "padding"</p><p>9. The transport is responsible for providing an org.jboss.tm.XAResourceRecovery to detect orphan subordinate transactions, this is also illustrated in the example, this *must* be the last registered XAResourceRecovery. The transports implementation of this class must use a transport specific implementation to talk to any possible server that a transaction may have flowed to in order to discover potential orphan transactions. This is because the remote side may have a prepared a transaction and then crashed before the local side has prepared therefore we have no other options available to us. In the example I hard code all the remote server nodes before hand, an alternative is to build this list up incrementally at each node as the transport detects a new remote server is being communicated with.</p><p>10. The call to com.arjuna.ats.jta.common.jtaPropertyManager.getJTAEnvironmentBean().setXaResourceOrphanFilterClassNames() should add a filter for: "com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateJTAXAResourceOrphanFilter"</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>When reading the example, one approach would be to look at: com.arjuna.jta.distributed.example.server.impl.ProxyXAResource as the local interceptor for an EJB (say) and consider its counterpart remote interceptor to be something along the lines of: com.arjuna.jta.distributed.example.server.impl.RemoteServerImpl. The rest of the code should fall into place when the responsibilities of these classes are understood, alongside the addtional work mentioned in actually bringing the server up in a mode that can recover a transports ProxyXAResource-esque class.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>Any problems please do let us know, it sounds a lot more complicated that it is in reality! The key part is getting the proxy registered and recoverable which hopefully the transport demonstrates in a relatively straightforward manner - not the use of classloaders in the example is to allow multiple transaction managers to run in the same VM - this is for testing and is not a requirement of this feature and can be largely ignored.</p></div>
<div style="background-color: #f4f4f4; padding: 10px; margin-top: 20px;">
<p style="margin: 0;">Reply to this message by <a href="http://community.jboss.org/message/642551#642551">going to Community</a></p>
<p style="margin: 0;">Start a new discussion in JBoss Transactions Development at <a href="http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2041">Community</a></p>
</div></td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</div>
</body>
</html>