On 2003.02.17 04:20 Ole Husgaard wrote: > 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.
Of course the information about whether an xid needs to be generated and a branch registered is available on the server side. My idea is to move this information to the client side, where the xid generation and branch registration actually happen. IMO this results in an easier to understand system with more appropriate division of responsibilities. The xid which I am using as the transportable transaction identifier is only available from the client side after the registration callback if the client is a JTA environment. > > 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. I agree this is necessary for CORBA, but I do not think it is appropriate for JTA based clients, such as other jboss instances. For simplicity and ability to interoperate with the clustering code, which chooses which server to communicate with in the invoker, I have made all java clients into JTA based clients. > 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. >From reading the 1.2 CORBA OTS spec my understanding is that CORBA does not support the transaction attributes (such as requiresNew and NotSupported) that would result in transferring a tx identifier but not importing it. Therefore if the CORBA client is JTA, I strongly suspect it will generate an xid for the branch from the transaction (if it exists) and send it along. This is exactly the behavior I am trying to avoid, since we have to support these types of tx support. > > 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.) umm, this was the original client side tx interceptor. > 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. And the resource registration occurs on the return of the original method invocation, or does it take an extra round trip immediately? The former incurs redundant bookkeeping requirements and the latter is inefficient. thanks david jencks > > 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 > > ------------------------------------------------------- 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
