[jboss-dev-forums] [JBoss Transactions Development] - Remoting Transport Transaction Inflow Design Discussion

[David Lloyd]

David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion

"Remoting Transport Transaction Inflow Design Discussion"

To view the discussion, visit: http://community.jboss.org/message/621318#621318

--------------------------------------------------------------
This is a starting point for discussion for the support of transaction control in conjunction with Remoting-based invocation.  All the items in this document are subject to discussion and revision!  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.

Problem:

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.  Historically, this has been accomplished using a remote view of UserTransaction.  This is simple to implement in a "thin" client, and is described in the first solution section.  However, implementing this in the context of a server communicating with another server is difficult.  Thus another approach is proposed below for this scenario, which has been described as "JTA inflow" or "JCA-style inflow".

Note that these two solutions are in addition to two other existing options: JTS and simply not supporting transactions.

0. Definitions

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.

1. Solution description (Remoting JTA client):

This solution applies to standalone, "thin" clients without a local transaction manager.

1.1. Client API and invocation

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.
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.
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.  (A connection may be shared across multiple client threads, thus it is possible for one connection to control many transactions.)
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.

1.2. Server side

1.2.1. Incoming transaction control commands cause transactions to be begun, committed, and rolled back.
1.2.2. Begun transactions are suspended and the resultant Transaction object is associated with the connection, along with the ID of the transaction.
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.
1.2.4. If the client session is lost or terminated, any outstanding Transactions are rolled back.

1.3. Unaddressed issues

1.3.1. Transaction timeout control

2. Solution description (Remoting JTA inflow):

This solution applies to servers with a local transaction manager.

2.1. Invocation, client side

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.
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.
2.1.2.1. Xid propagation should rely on a byte representation, not a serialized object, in order to support multiple marshalling schemes.
2.1.3. Transaction control methods invoked upon the XAResource will be forwarded as commands over the Remoting channel to the server.

2.2. Invocation, server side

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.
2.2.2. Incoming XAResource commands will be translated into invocations on the local XATerminator (or equivalent) to carry out transaction completion.
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.

2.3. Recovery

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.  The client is always treated as the originator of the transaction.
2.3.2. The client invocation context must expose a means to acquire its XAResource in order to facilitate local recovery.

2.4. Unaddressed Issues

2.4.1. Transaction timeout control
--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/621318#621318]

Start a new discussion in JBoss Transactions Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2041]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20110816/a3028d06/attachment.html