2:19 p.m.
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&...]