David Jencks wrote:
I am a little bit confused here. What do you mean by "client starts tx"? For example, if the client is a standalone app, will this app actually create instance of TransactionImpl and be responsible for executing two phase commit protocol? You'll have hard time recovering from failures of such clients. Even if you provided full-blown transaction manager with tx logs and proper recovery algorithm on the client side, the client can simply quit after executing phase one of 2PC and never come back. Have I missed something?The design goal is to produce a working dtm that does not make unnecesary inter-vm calls. The functionality of the client side tx interceptor appears to be unavailable with the CORBA OTS if we do not write some client side stuff.Here is the sequence of events for a call between vms where a transaction is started on the client (could be a standalone app or a JBoss instance) client starts tx client calls ejb proxy client side tx interceptor attaches tx to invocation ONLY if tx support for the method is supports, mandatory, or requires. In all other cases it makes sure no tx is attached to the invocation. invocation is routed to correct transport mechanism (such as by the HA Invoker interceptor)(AFAIK not yet written as an interceptor) Now that we have the target jboss instance determined, the InvokerXAResource enlists with the tx if present, thus getting an xid to transport. If no tx is present, it doesnt enlist with null. The xid is sent over the transport mechanism with the marshalled invocation. The server-side half of the transport mechanism/invoker extracts the xid if present, puts in in an ExcecutionContext, and uses the WorkManager associated with the invoker to execute the call to the ejb. The WorkManager communicates with the server-side tx manager to start and end the transaction at the beginning and end of the call. The method returns. At some later time, the tx commits. Since the InvokerXAResource was enlisted in the tx IF AND ONLY IF the tx was actually sent to do work on the server jboss instance, it will get a commit call only if the server jboss instance actually did work in the tx. If it did work in the tx, it gets (possible) prepare and commit calls with the xid for its branch, and makes a invocation to call an XATerminatorContainer, which has the same method call syntax as an ejb container. In any case it handles communicating the prepare and commit calls to the server-side tx manager.
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
