Hi,
We have an old (currently very minor) problem, that
I would like to see fixed:
Each container has it own TM reference. While these
are currently all to the same TM instance I think the
general idea is that different containers should be
allowed to have different TMs.
The problem is that on outgoing calls from the beans
in the container we need to know the TM in order to
propagate the right transaction. For this the class
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy
has a class variable tm that refers to some TM of
some container. But GenericProxy is shared between
all code in the VM.
In org.jboss.ejb.plugins.jrmp.JRMPContainerInvoker
the following code snippet can be found in the init()
method:
// Set transaction manager
GenericProxy.setTransactionManager(container.getTransactionManager());
// Unfortunately this be a problem if many TM's are to be used
// How to solve???
This ensures that "some" TM is set in the GenericProxy,
but not that "the right" TM is set.
Tricky issue. We want to use the TM of the container
of the bean that calls out, so GenericProxy.tm should
be an instance variable rather than a class variable.
That gives us the problem of finding the TM at call out
time instead of at initialization time.
I was thinking about adding a reference to the container
or the container's TM to the BeanClassLoader, but
BeanClassLoader is gone now and I really don't want to
complain about that.
Guess we could use a JNDI lookup in the container-local
JNDI space (after having added the TM to that), but that
would probably be too slow as it should be done at
_every_ outgoing call.
But we still have a per-container classloader, so maybe
we could play some tricks with that: If we make sure
that GenericProxy is loaded by each container's
classloader, each container would have its own
GenericProxy class, and a class variable tm would be
OK ?
Unfortunately my experience with classloaders can be
summarized as: "Multiple classloaders may cause problems
like ClassCastExceptions."
So before pursuing this path, I'll better ask the
experts here...
Would loading GenericProxy by the container classloader
be useful here?
Would it really solve the problem?
Would it cause other problems?
How about subclasses of GenericProxy? Would these have
to be loaded by the container classloader too?
How about the real (generated) proxies? Would I get
problems with these?
Best Regards,
Ole Husgaard.
