|We have an old (currently very minor) problem, that
|I would like to see fixed:
we have other problems, namely optimizeIt says we spend 40% of our time in
Tx.begin() :P
;-)
onto what you are saying
|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
The class variable refers to the TM of the client VM not the server VM.
|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());
I don't know where that came from... the TM is supposed to be static in the
client VM (last I checked)
| // 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.
correct, but if it is a static reference to the TM it can be class.
|That gives us the problem of finding the TM at call out
|time instead of at initialization time.
hence the static
|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.
yes, however you can do stuff at "deserialization" of the GenericProxy
|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."
LOL
|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?
I am not sure, the TM as container variable, travelling to the client with
the Proxy, is something I don't understand.
I mean your client obtains a JTA interface to the TM and it needs to be the
one of the distant bean container??? the way it works now is local and
works for bean to bean.
|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?
marc
|
|
|Best Regards,
|
|Ole Husgaard.
|
|
