<!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;">
    Remoting Transport Transaction Inflow Design Discussion
</h3>
<span style="margin-bottom: 10px;">
    created by <a href="http://community.jboss.org/people/dmlloyd">David Lloyd</a> in <i>JBoss Transactions Development</i> - <a href="http://community.jboss.org/message/621318#621318">View the full discussion</a>
</span>
<hr style="margin: 20px 0; border: none; background-color: #dadada; height: 1px;">

<div class="jive-rendered-content"><p><p>This is a starting point for discussion for the support of transaction control in conjunction with Remoting-based invocation.&#160; All the items in this document are subject to discussion and revision!&#160; There will be a design conference call among the concerned parties in which the details of these points will be worked out; afterwards, a revised version of this document will be made available for any further discussion.</p><p id="magicdomid4036" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid91">Problem:</p><p id="magicdomid92" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid4721">It is required that in order to maintain the appropriate level of compatibility with previous releases, the Remoting EJB transport must support a means by which the transactional state of the server can be controlled.&#160; Historically, this has been accomplished using a remote view of UserTransaction.&#160; This is simple to implement in a "thin" client, and is described in the first solution section.&#160; However, implementing this in the context of a server communicating with another server is difficult.&#160; Thus another approach is proposed below for this scenario, which has been described as "JTA inflow" or "JCA-style inflow".</p><p id="magicdomid4723" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid4813">Note that these two solutions are in addition to two other existing options: JTS and simply not supporting transactions.</p><p id="magicdomid1940" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3400">0. Definitions</p><p id="magicdomid3389" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3390">0.1. Client invocation context - the context associated with a thread on the client side of an invocation, which in turn relates to a specific Remoting connection providing its transport.</p><p id="magicdomid3391" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3402">1. Solution description (Remoting JTA client):</p><p id="magicdomid4414" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid4467">This solution applies to standalone, "thin" clients without a local transaction manager.</p><p id="magicdomid1978" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3403">1.1. Client API and invocation</p><p id="magicdomid2013" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3404">1.1.1. The client will control transactions on the server using a variation of the UserTransaction interface, which may be accessed via JNDI or other mechanisms in place of a TM-provided UserTransaction implementation.</p><p id="magicdomid3406">1.1.2. Any initiated transaction will be associated with the client thread and client invocation context, and assigned a simple ID which is associated with remote invocations made by that thread during its duration.</p><p id="magicdomid3408">1.1.3. The implementation of this interface will use a simple Remoting-based protocol to forward the method invocations to the server along with the ID of the transaction in question.&#160; (A connection may be shared across multiple client threads, thus it is possible for one connection to control many transactions.)</p><p id="magicdomid3410">1.1.4. Upon invocation, the client will attach the ID associated with the current thread's transaction to the invocation as a "transaction ID attachment" as it is executed.</p><p id="magicdomid2309" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3411">1.2. Server side</p><p id="magicdomid2322" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3412">1.2.1. Incoming transaction control commands cause transactions to be begun, committed, and rolled back.</p><p id="magicdomid3428">1.2.2. Begun transactions are suspended and the resultant Transaction object is associated with the connection, along with the ID of the transaction.</p><p id="magicdomid3593">1.2.3. Incoming invocations with a transaction ID attachment are associated with the suspended Transaction, and the Transaction is resumed for the duration of the method invocation.</p><p id="magicdomid3759">1.2.4. If the client session is lost or terminated, any outstanding Transactions are rolled back.</p><p id="magicdomid3595" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3613">1.3. Unaddressed issues</p><p id="magicdomid3615" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3653">1.3.1. Transaction timeout control</p><p id="magicdomid3654" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3416">2. Solution description (Remoting JTA inflow):</p><p id="magicdomid521" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid4577">This solution applies to servers with a local transaction manager.</p><p id="magicdomid4469" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3418">2.1. Invocation, client side</p><p id="magicdomid564" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3419">2.1.1. Upon invocation, the client will locate (via the local TransactionManager) the current active Transaction and enlist into it an XAResource instance corresponding to the client invocation context.</p><p id="magicdomid4605">2.1.2. The Xid and any pertinent ancillary information regarding the current transaction which were provided to the XAResource will be attached to the invocation as a "transaction inflow attachment" as it is executed.</p><p id="magicdomid4720">2.1.2.1. Xid propagation should rely on a byte representation, not a serialized object, in order to support multiple marshalling schemes.</p><p id="magicdomid3421">2.1.3. Transaction control methods invoked upon the XAResource will be forwarded as commands over the Remoting channel to the server.</p><p id="magicdomid1129" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3422">2.2. Invocation, server side</p><p id="magicdomid1152" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3423">2.2.1. Incoming invocations which have a transaction inflow attachment will trigger the use of an interceptor which utilizes the XATerminator (or equivalent) interface to import the transaction for the duration of the invocation execution.</p><p id="magicdomid3881">2.2.2. Incoming XAResource commands will be translated into invocations on the local XATerminator (or equivalent) to carry out transaction completion.</p><p id="magicdomid4032">2.2.3. If the client session is lost or terminated, any open transactions are rolled back; any prepared but incomplete transactions have to be recovered manually.</p><p id="magicdomid1432" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3425">2.3. Recovery</p><p id="magicdomid1444" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3426">2.3.1. The client is expected to use "JTA top-down recovery", which will treat the participating server(s) as additional local resources to recover.&#160; The client is always treated as the originator of the transaction.</p><p id="magicdomid3427">2.3.2. The client invocation context must expose a means to acquire its XAResource in order to facilitate local recovery.</p><p id="magicdomid3760" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3781">2.4. Unaddressed Issues</p><p id="magicdomid3783" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p><p id="magicdomid3819">2.4.1. Transaction timeout control</p><p id="magicdomid3880" style="min-height: 8pt; height: 8pt; padding: 0px;">&#160;</p></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/621318#621318">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>