Hi, Deciding to avoid the resource registration callback when the tx is not used at server side is a fine thing.
However, I fail to see why this decision has to be done at the client side. All the information needed for the decision is already available at the server side. For CORBA, I think we should to things the CORBA way: Always propagate the tx (if one is available at client side), and let the server side TM (or interceptors) decide if a resource registration callback is needed. Most CORBA implementations always do the registration callback, as the import of the tx is done in the transport code. But by using a custom CORBA tx interceptor at the server side, we can simply store the xid in a threadlocal, and delay the tx import until we know if it is needed. So, why not use this sequence of events: 1) client starts tx 2) client calls ejb proxy 3) (NO client side tx interceptor. Always attaches tx to invocation.) 4) invocation is routed to correct transport mechanism (such as by the HA Invoker interceptor)(AFAIK not yet written as an interceptor) 5) Invocation is received at server side. 6) The server decides if the resource registration callback is needed. Best Regards, Ole Husgaard. 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. > > ---------------------- > > 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. > > 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. > > 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
