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. 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.

Second, Tyrex is an activatable RMI server. How does that fit into the
MBean structure? Are these all valid scenarious of using Tyrex?

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?

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 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? 

There is practically no documentation about Tyrex, so I have to go to the
Source :) for everything.

Any ideas how I should proceed?

Anatoly.


On Wed, 7 Mar 2001, Ole Husgaard wrote:

> Hi,
> 
> Anatoly Akkerman wrote:
> > In the light of Marc's answer, I was wondering, exolab (www.exolab.org)
> > has a functioning distributed transaction manager called Tyrex. It
> > implements the necessary specs and has been tested (near 1.0 version at
> > this point) and should be pluggable into JBoss. Can the future
> > implementation of JBossTX be based on Tyrex, instead of reinventing the
> > wheel?
> 
> IMO, JBoss should be independent of the
> transaction service used.
> Most of the required independence is
> already in place, and only the thread
> association in the interceptor chain
> still use constructs specific to the
> current JTA implementation. But that
> shouldn't be hard to change.
> 
> On the wire (with the JRMP transport),
> the transaction propagation context
> is of type java.lang.Object, so any
> serializable object can in principle
> be used as the transaction propagation
> context (TPC).
> 
> To support another transaction service
> that implements the JTA api, all you
> need is to write a MBean for it. An
> example MBean is the current MBean
> implementation in org.jboss.tm.
> The MBean should add three entries to
> JNDI:
> 1) A TransactionManager instance
> reference. This makes it possible for
> JBoss to look up the TM.
> 2) A TPC Factory. This converts the
> internal transactions to TPCs that can
> be transported over the wire.
> 3) A TPC Importer. This converts TPCs
> to Transactions that can be used in
> the local VM.
> 
> Please note that no UserTransaction
> needs to be available. For CMT, the
> UT is part of the container who
> intercepts UT invocations and end up
> calling the TM.
> For stand-alone clients, with no
> local transaction service, I am
> working on a service that delegates
> to the server TM, and is also
> independent of the transaction service
> used in the server.
> 
> 
> So once the last calls to the TxManager
> specific methods disassociateThread()
> and associateThread() have been
> replaced with calls to suspend() and
> resume(), adding support for other
> transaction service implementations
> should be simple.
> 
> 
> > And if not, then as a temporary solution:
> > Would others find it useful if I try integrating Tyrex as an MBean for
> > JBoss?
> 
> I think that a lot of people would
> find that *very* useful, myself
> included.
> Not just as a temporary solution.
> Even if we end up also supporting
> other transaction service
> implementations: If Tyrex can run
> as a MBean under JBoss, no format
> conversion is needed when
> interoperating with other servers
> that use Tyrex, so interoperability
> here would be smoother and faster.
> 
> If you think you are game for such
> a project, I wouldn't mind helping
> out as best I can.
> 
> 
> Best Regards,
> 
> Ole Husgaard.
> 
> 


Reply via email to