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

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

> This just looks like a bug in Hibernate. 
> 
> It is caching the naming context in the JTATransactionFactory
> and then using it concurrently across threads, without 
> the required synchronization.
> 
> This probably only works by luck, because it is looking up in
> "java:comp" for the UserTransaction which is a read only context
> constructed at deployment time and is therefore unlikely 
> to have concurrency problems.
> 
> I'm sure if this class was changed to create a new initial context
> for each request you wouldn't see the contention, but that
> might not be very efficient either. Depends how often the
> isTransactionInProgress() is invoked.
> 
> I don't see why it isn't caching the UserTransaction instead anyway.
> It's probably because some people use Hibernate across transaction
> demarcation boundaries in at least dubious, if not broken ways. :-)