I'm now quite confused about what you are arguing for. 1. There is currently no support whatsoever in any jboss version for transactions over CORBA/IIOP, nor has there ever been. I have not yet considered how best to implement this. I don't think this will be used very much so I am willing to provide a special implementation for this if it will not fit into the jta framework well.
2. I can't tell from the specs I have read so far what the relationship between the CORBA tx policy and the j2ee tx policy is supposed to be. 3. JTA performs the registration of the branch at the same time as the xid is generated through the tx.enlist(XAResource) and xares.start(xid) calls. There is no other way to get an xid. 4. Your final arguments look to me as if they are supporting exactly what I implemented. Are you aware that the current implementation works only with the trunk invoker? Are you aware that the InvokerXAResource is a client-side mbean? thanks david On 2003.02.18 09:52 Ole Husgaard wrote: > 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 > > ------------------------------------------------------- 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
