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