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.
