David Jencks wrote: > On 2003.02.17 04:20 Ole Husgaard wrote: > > 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.
If deciding if the tx is needed in the server is done on the server side - as I suggest - an xid will still be generated and transmitted from the server side. But these are relatively cheap operations. The really expensive operation is the callback done to the client for registering the server TM as a resource to the client TM, because of network latency. > IMO this results in an easier to understand > system with more appropriate division of responsibilities. I think that letting the server decide if the server needs the tx is more logical. However, letting the client decide can also be implemented in a understandable and maintainable way, as only a few specialized interceptors are involved. > > 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. For JRMP, we define our own protocol, so here we can do whatever we like. My concern is about the IIOP transport: This should not have any special hacks that could break interoperability with non-java code. > > 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. CORBA has OTSPolicy, but that doesn't map directly to the EJB transactional attributes. For example, there is no equivalent of requiresNew. However, OTSPolicy could be used to sometimes avoid generating a new branch at the client, and transferring it to the server. Unfortunately, I don't think that JacORB supports OTSPolicy. > 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. Still, these operations are relatively cheap. The expensive operation is the callback to the client to enlist the server as a resource in the client TM. > > 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. Yes.. > > 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. The last step is where I see the possibility for avoiding the expensive registration callback. When the server receives an invocation with a transaction id, the transaction has to be imported to ensure that a local Transaction exists, and this is done with the TransactionPropagationContextImporter interface. On import, the callback happens (if needed). In the old JBoss code, there way really no decision if the server should import the tx - instead it was always imported. But the server knows if it needs the tx, and can avoid this import in this case. That would be possible even with the IIOP transport, even in the absense of OTSPolicy support, and without breaking CORBA interoperability. > 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. Avoiding the extra round trip is what I am interested in here. Optimizing the server TM "resource" registration by doing it before or after the call is tricky. Please consider recovery after failures. The resource registration should be done either by a registration callback (inefficient), or by the client before the invocation. If the registration is done at return time, a client VM crash would result in an orphaned transaction branch in the server. Registration before the call might be possible with recovery support. Best Regards, Ole Husgaard. ------------------------------------------------------- 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
