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

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. :-) _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development