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

[Mark Little]

On 12 Jul 2007, at 18:13, 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?

JTS knows nothing about UserTransaction. The closest equivalent is  
OTS::Current.

UserTransaction works on the thread-to-transaction association. Some  
implementations I've seen give out a thread specific instance of  
UserTransaction. But the common implementation is one instance that  
does the multiplexing behind the scenes, so you can share the same  
instance between multiple threads.

Mark.


>
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
>

----

Mark Little
mlittle at redhat.com

JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod  
Street, Windsor, Berkshire,
SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David  
Owens (Ireland)




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-development/attachments/20070712/3dee49c3/attachment.html