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

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.