[jboss-dev] Oops, javax.naming.spi.* is dependent on Hashtable , this will make it difficult to change the JBoss jndi naming service to use ConcurrentHashMap instead of Hashtable...

[Adrian]

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!)

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx