|
Hi David,
Sorry for not getting back to u sooner. > On Monday, March 22, 2004, at 11:30 AM, Dasarath Weeratunge wrote: > > > Hi all, > > > > Will Geronimo be using TyRex as its transaction manager? > > Definitely not. > > What is the transaction manager that is in use at the moment in Geronimo or that u plan to use? Can Geronimo use JOTM? (LGPL 2.1 or later) I managed to get JOTM working with JOnAS 4.0. What I'm interested in is the interface between the transport layer interceptors and rest of the JTS impl. This is the interface that Axis handlers will use. Different Impls tend to do different things here. We may also use the javax.jts.TransactionService/identifyORB and let the tm identify its sender/receiver callbacks to Axis. > > Can you please explain how many vms are involved in your scenario and > where the transaction control resides? If you are running axis in a > different vm from Geronimo can you please explain why? To my present understanding, Axis and JOTM (or whatever JTS impl that will be used) needs to be in the *same VM* so the association b/w thread and tx-context can be preserved. Transaction control will be in the JTS impl. The basic idea is for ws to ejb calls, axis handlers to create wrapper objects that wrap the respective web services and pass them to the JTS impl in place of the remote objects that it would have got from the normal RMI transport. This way, the domain where the transaction originated (from ws or J2EE) will be transparent to the transaction manager. When an ejb makes a ws call, exported remote objects handed over to the transport layer by the JTS impl will be wrapped using wrapper objects again. In short we are writing a new CRM using axis and connecting that to the JTS impl. This CRM will however *not be* JTS impl independent. From the perspective of jsr 109 impl, Axis *need not be* in the same VM as Geronimo, since we are using the remote interface. This was proposed to keep the jsr 109 impl app server independent. Anyway, in the case Geronimo Axis will be in the same VM. > If you need to > import transactions I suggest you consider using the jca 1.5 mechanism > using WorkManager/ExecutionContext and XATerminator. This is already > implemented and appears (with limited unit testing) to work. > Propagation of transactions between vms is not yet implemented but > will (IMO) make use of the networking layer and the same transaction > import facilities as the jca 1.5 implementation. The jca approach seems fine but we may have to take the present ews remote invocation code from the wrapper web service and put it in the Work object. Since jca supports jaas anyway, it should not interfere with the security impl either. However, there are two concerns. 1-Can we have axis and the resource adaptor running in the same VM? This way we could pass the work object from the wrapper web service to the adaptor at run time. 2-Can we use the jca method for exporting transactions - that is when ejbs invoke web services? Appreciate ur comments. Dasarath |
- Geronimo/jsr 109 ws-at impl Dasarath Weeratunge
- Re: Geronimo/jsr 109 ws-at impl David Jencks
- Re: Geronimo/jsr 109 ws-at impl Srinath Perera
- RE: RE: Geronimo/jsr 109 ws-at impl Dasarath Weeratunge
- RE: RE: Geronimo/jsr 109 ws-at impl Dasarath Weeratunge
