[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...

[Steve Ebersole]

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