> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of David > Jencks > Sent: Wednesday, February 12, 2003 11:42 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] TxInterceptor split is really really good > > > 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)
Ok, its now time to split this HA stuff out....I'll work on that now....Of course, unfortunately, this split requires an InvocationResponse object. > 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. > This is all TrunkInvoker stuff, correct? Now why the reliance on TrunkInvoker? Couldn't you just create a new Invocation object and pass it down the interceptor chain? I guess this would break in the current implementation of clustering though as you say above.... > 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. > > ---------------------- > > Of course, with optimized in-vm calls, you don't have an InvokerXAResource > and don't generate an xid for the method call. > > ---------------------- > > Now lets consider the alternative. Without knowing the tx > support of every > method in the ejb, EVERY transaction MUST be ALWAYS enlisted with the > InvokerXAResource, have an xid generated for it, get transmitted over the > transport mechansim, and enrolled in the server-side transaction manager. > Then when commit comes, totally useless prepare and commit calls must be > made to a remote vm for a transaction that COULD NOT POSSIBLY > HAVE DONE ANY > WORK. We have one remote call to do the requested work and up to > two calls > to no purpose. > Ok, back to the InvocationResponse thingy we were discussing offline.... What is this InvokerXAResource? Is it on the client/initiating TM of a distTrans that represents the remote TM? Why does an XID have to be generated before the call to the remote TM? Is it required that the client TM generate the Xid that the server must use? Why can't the client side insert a boolean flag(or the client Xid?) in the Invocation object to let the remote TM know that it belongs in a distTrans. On the server side, an interceptor reads this boolen flag(Xid), starts a transaction, associates the new TX with the current thread. The server generates an XID and stuffs it in the InvocationResponse object. On method completion, the client receives the InvocationResposne object, extracts the Xid from the InvocationResponse, and finally does the XA enlisting. If there is no Xid in the InvocationResponse object, the client doesn't have to do any enlisting. Is there a reason the enlisting needs to happen before the method call executes? Or is it required that the client TM generate the Xid? > It may seem unlikely that a small client would start a user > transaction and > then call an ejb method that didn't use it, but it seems considerably less > implausible to me that a jboss server would call, within a transaction, a > remote ejb with a non-transactional method. > I'm not sure what you're saying here. Are you saying these scenarios won't work in your current scheme? > > Looking at the OTS 1.2 spec, I notice that they do not use xids > to identify > branches. The tx support model appears to only support the equivalent of > never, supports, and mandatory. Therefore, if a tx is present in an > invocation, either an exception will be thrown or it will be used. > Although no xid can be supplied by the OTS, jboss will still be > responsible > for calling coordinator.register_resource(jboss-resource) back in > the corba > client. I have no idea how the remote part of corba works, but it would > obviously be advantageous to have something analogous to the > InvokerXAResource in the client making this call rather than requiring a > call back from jboss. > > david jencks > > On 2003.02.12 16:31 Bill Burke wrote: > > What if you don't have java on the client side? What if you're CORBA > > with > > OTS? You're making it harder for Non-JBoss/Java clients to integrated > > with > > us. I think this split should be undone. > > > > BTW, why the split besides code readability? Is the DTM dependent on > > this > > at all? Is the TM even accessed on the client side? > > > > Another problem I see is that the TxMethod map is required on the client > > side as well. Makes proxies even more heavy and what do you do about a > > hot > > deploy? > > > > Seems to me this is a bad idea. > > > > Bill > > > > > > > > ------------------------------------------------------- > > 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 ------------------------------------------------------- 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
