Re: [jBoss-Dev] Distributed transactions (Tyrex & JBoss)

[Anatoly A. <akk...@cs...>]

Hello, Ole

I am taking you up on your offer to help me out figure out things with
Tyrex. I've been browsing through Tyrex source for about a week already
and seem to be running into a wall. I wanted to clarify with you a couple
of things about the way DTMs work and see, perhaps I am missing something.

Here is a case scenario that would require a DTM.

JBoss1 (first instance of JBoss, say running on machine 1)
BeanA with method M1 which requires transactions is deployed on JBoss1.
There is an instance of a DTM running inside JBoss that acts as the
JBoss TM.

JBoss2 on machine 2.
BeanB with method M2 that gets called from BeanA which runs on JBoss1.
There is an instance of a DTM running inside this instance of JBoss as
well and it acts as the JBoss TM.

Let's assume CMT beans for this scenario.

M1 of BeanA gets called. An interceptor in JBoss1 (TxInterceptorCMT)
creates a new transaction for this method invocation. BeanA from within M1
calls BeanB, method M2. Given that this bean is remote, JBoss1 packs
together a MethodInvocation, which contains among other things, a
TransactionPropagationContext object that was created by
TransactionPropagationContextFactory from the current Transaction object
(this factory is a DTM-specific class that packs along all the necessary
info into the TPC).  

An RMI call into JBoss2 happens and the MethodInvocation gets unpacked
along with the TPC. The invocation chain reaches the TxInterceptorCMT in
JBoss2 where in runWithTransactions Transaction object gets obtained from
the MethodInvocation object (MethodInvocation.getTransaction), this in
turn extracts (or creates) a Transaction object from MethodInvocation
using the TransactionPropagationContextImporter. From this point on, this
Transaction (say, oldTransaction) is associated with this invocation by
calling tm.associateThread(oldTransaction).

Assuming we will rewrite the JBoss so that it delists XAResources from a
current transaction associated with a thread, suspends this transaction
and now wants to associate a new transaction that came along from the
MethodInvocation by calling resume() of the TransactionManager (all this
instead of using non-standard associateThread() and dissociateThread()).
As far as I can understand, the application server needs to enlist all the
previously delisted XAResources of this transaction prior to resuming it.
Wouldn't the XAResources of the transaction propagated from JBoss1 into
JBoss2 have to be passed along so that the get enlisted when transaction
resumes in JBoss2? 

I am not really clear on how a transaction created in one TM gets
propagated into a different TM. As far as I can understand, after M2
returns, and then M1 returns, Jboss1 would have to commit the transaction.
How does the TM of Jboss1 communicate the commit to XAResources enlisted
while the transaction was in JBoss2? Some kind of references have to be
passed back and forth? or the transaction should really be implementing
Remote, so only its stub gets passed to JBoss2?

...

I am at loss how this stuff works...

Anatoly.


On Mon, 12 Mar 2001, Ole Husgaard wrote:

> Hi,
> 
> [CC-ing to jboss-dev in case somebody
> can reply to the things I do not know
> about.]
> 
> Anatoly Akkerman wrote:
> > 
> > I have started looking at Tyrex and wanted to take you up on helping me
> > figure things out.
> > 
> > First and foremost, Tyrex seems to have a few extra things whose place
> > in JBoss I am not sure about.
> > 
> > First, it seems to supply its own JNDI implementation.
> 
> If we can start the transaction service
> without starting the JNDI service, we
> should get no problems here.
> 
> > My initial
> > impression was that if we integrate it into JBoss, it should use JBoss's
> > naming service. Presumably, this can be configured by jndi.properties that
> > Tyrex will encounter on startup that will point to the jboss's naming
> > service implementation.
> 
> Yes, I think this should work.
> 
> > Second, Tyrex is an activatable RMI server. How does that fit into the
> > MBean structure? Are these all valid scenarious of using Tyrex?
> 
> I do not think we should get any problems
> using RMI. It seems to work fine with RMI
> client and server from MBeans.
> Only "problem" I have seen is that RMI
> server implementations log as if they
> are [JMX RMI Adaptor], but I guess even
> this could be fixed like LogInterceptor
> does for EJBs.
> I do not know about RMI activation, but
> distributed garbage collection seems to
> work well in servers started from a
> MBean.
> 
> > 1. Tyrex was started stand-alone, registered itself with rmid and JNDI.
> > JBoss is started afterwards and it has a Tyrex MBean that simply looks up
> > JNDI or RMI registry to locate Tyrex server. After the server is located,
> > the Tyrex MBean makes a TransactionManagerImpl available for JBoss through
> > a well-known JNDI name. In this case the calls to Tyrex would go into a
> > different VM?
> 
> Having the transaction service in a seperate
> process seems to be common. No problems with
> that, except for the overhead of IPC.
> But when running stand-alone, the JNDI server
> of Tyrex will probably have to be started on
> a seperate port (probably uses port 1099 like
> most other implementations).
> 
> I am not sure how to get to another JNDI
> service by another vendor.
> 
> > 2. Tyrex was started as part of JBoss. Here we have more control of its
> > configuration. I am wondering what do we do about Tyrex's attempts to
> > register with an rmi daemon, we need one started as well?
> 
> I guess so. Maybe we could and start and stop
> it from within the MBean, but it would
> probably be cleaner to depend on a rmid
> MBean that is implemented seperately as
> part of the JBoss core.
> 
> Running Tyrex within the JBoss VM
> will probably give the best performance.
> 
> > I have not had any previous experience with TMs and DTMs plus I am
> > relatively new to JBoss (hacking with it for the past couple of months),
> > so there is some learning curve here. Am I correct in assuming that Tyrex
> > is supposed to run only on one JBoss server and the rest are supposed to
> > connect to this same instance in order to have distributed transactions
> > between each other?
> 
> No, I think that you should start it in each
> JBoss VM. It needs to set up remote interfaces
> for two-phase commit or rollback, and it
> probably wants to do interposing too (a
> technique for optimizing remote two-phase
> commit).
> Also the MBean sets up the TM in the local
> java: JNDI space, and JBoss needs that.
> 
> 
> > There is practically no documentation about Tyrex, so I have to go to the
> > Source :) for everything.
> 
> Seems to be that way with all opensource
> tx services I've seen...
> 
> 
> > Any ideas how I should proceed?
> 
> I suggest you use package name 
> org.jboss.tm.plugins.tyrex for all
> your interface code between JBoss
> and Tyrex.
> 
> Please do not reinvent the wheel:
> Copying the current TM MBean and
> modifying it may be easier than
> starting from scratch, but please
> remove old author names.
> 
> The class implementing the object
> used as a transaction propagation
> context has to be loaded from the
> VM classpath. Loading it from the
> MBean gave me big trouble (very
> bad performance) until I figured
> this out with help from Marc and
> Rickard.
> Maybe it will be the easiest to
> just add the Tyrex jar to the
> classpath.
> 
> 
> Don't hesitate to ask me if you have
> more questions, or run into some kind
> of trouble with it. If full source is
> available to Tyrex, we can make it
> work even if a Tyrex patch is needed.
> 
> 
> Best Regards,
> 
> Ole Husgaard.
> 
>