Re: [jboss-dev] Oops, javax.naming.spi.* is dependent on Hashtable?=, this will make it difficult to change the JBoss jndi =?utf-8?q?naming service to use ConcurrentHashMap instead of Hashtable...
I am doing a training all this week, so I have not really had time to fully consider all
of the replies from this thread. Next week when I'm back in Austin I'll be able
to give this more proper consideration and reply...
On Thursday 12 July 2007 12:59:19 pm Adrian wrote:
On Thu, 2007-07-12 at 12:13 -0500, Steve Ebersole wrote:
> Does JTA/JTS mandate that a UserTransaction reference obtained and held indefinitely
understand the context in which calls against it are invoked? And that it react
accordingly?
>
> If so, then no big deal I can change this.
>
> As background, JTATransactionFactory is scoped via a SessionFactory. So if
JTATransactionFactory were to cache this reference, it would be cached for the duration of
that SessionFactory (hence my question above).
>
> The only reason I did it this way was perhaps a misunderstanding of how
UserTransaction worked in this scenario (based on question above). As always, my JTS
knowledge pales in comparison to yours. If I misunderstood the above please let me
know...
>
In principle the UserTransaction is just a stateless front end
to the TransactionManager (restricting access to certain methods).
That's certainly how it works for web-apps.
For EJBs its more complicated.
The UserTransaction can certainly be cached by the BMT bean.
But there are restrictions on when you can use it, see the EJB spec.
I don't think the caching changes these semantics in the simple cases.
The real question is would this lead to one bean using a UserTransaction
from another bean?
If so, then the checking done about when the UserTransaction
can be used might not work as expected.
e.g. (I'm talking about different ejbs NOT
different instances of the same ejb here)
caller -> BMT SLSB1 (cache UT1)
returns and then invokes
caller -> BMT SLSB2 (uses UT1 instead of UT2?)
If BMT SLSB2 really does used the cached version
(same session factory if I undertand correctly) then
this will probably fail because you can't use UT1
since you are not in a method of BMT SLSB1.
If this really is a problem, then you have
other problems already without this change, e.g.
caller -> BMT SLSB1 (can lookup UserTransaction)
caller -> CMT SLSB2 (no user transaction here, oops!)