David Jencks wrote:
On 2003.02.15 09:57 Igor Fedorenko wrote:
David Jencks wrote:
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.
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?
Yes. I wouldn't recommend doing a multi-participant tx from a standalone
client, but if you want to risk it you can.
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?
My first implementation was with a limited client tx manager that would
only handle one branch. After some encouragement from other developers I
changed to always using the same tx manager and tx implementation
everywhere. By default a standalone client is set up without tx logging.
Having only one tx/txmanager implementation results in less code and
equivalent behavior if the client is sensible and only uses 1pc. The 2pc
stuff is mostly intended for server instance to server instance calls, but
if you want to stick your neck out from a standalone client I don't see why
I should try to stop you.
Does this seem reasonable?
Thanks for the explanation, David. This all makes perfect sense to me.
--
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
