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 david > > -- > 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 > > ------------------------------------------------------- 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
