David Jencks wrote: > I'm now quite confused about what you are arguing for.
Basically I am arguing that it seems more logical to let the server decide if the server needs the transaction, instead of offloading this decision to the client. That approach involves some (cheap) local bookkeeping in the client and the transmission of an unneeded tx id. But it is still possible for the server to avoid the expensive import of that tx id. However, I have no strong feelings against your approach - as long as it is not done for the IIOP transport. But I was worrying if you were about to do the same thing for the IIOP transport - which could break interoperability with non-Java CORBA clients. > 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. Support for full JTA/OTS interoperability is possible because the tx id in JBoss is basically untyped (java.lang.Object). When a transaction comes in, the TransactionPropagationContextImporter implementation will see a org.omg.CosTransactions.PropagationContext if the call comes in via IIOP, and if the call comes via JRMP it will have whatever type you decide to use (currently GlobalId, but that does not hold the tx branch id). The JTA TM can use this type to find out how to communicate with the originating TM. For outgoing calls, the TransactionPropagationContextFactory interface is used. This may have to change, so that a specific type of wire tx id is requested by the outgoing transport code. When an OTS id is requested, an org.omg.CosTransactions.PropagationContext instance is returned after the TM has set up the needed OTS callback server. This way, we can support both IIOP and JRMP with transactions, without worrying if IIOP clients and servers are Java-based, or implemented in other languages. I currently don't need this, but I think we should keep in mind that someone might need it some day. > 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. It looks to me like JacORB is still at OTS 1.1 (ie. pre-OTSPolicy), so this may not be relevant yet. But when JacORB gets up-to-date on this, we may want to use the OTS tx policies. The OTS policy only supports the equivalents of never, supports and mandatory. Since the policy is included in the address (IOR), the client knows if it needs to send a tx id along with the call. Unfortunately, the OTS policy can only be defined at the object level and not at the method level, I think. > 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? What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Best Regards, Ole Husgaard. ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
