> My patch doesn't use a different TSR per thread, it just put a different instance of the javax.transaction.Transaction into the ThreadLocal, so that a different Transaction is used per thread (as per the JTA spec).
Well, we are only using the Transaction interface to do a small number of things, and while it may seem attractive to use a ThreadLocal for this, it's a bit bizarre because the same ThreadLocal is permanently assigned to the thread so the Transaction never changes. This is not per the JTA spec
> That being said, there are plenty of other solutions to this problem. The advantage I see to my solution is that it doesn't introduce additional unnecessary synchronizatin into the findTransactionalBroker() method. However, even if a different solution is desired, my patch should probably be applied anyway, since having the same Transaction instance being used from multiple threads might break other assumptions elsewhere.
I think in the case of TSR, there is a much more elegant solution to findTransactionalBroker, by using the getResource and setResource methods. These methods should be much more efficient than our own synchronized _transactional.get(key). Then the only use for _transactional is to make sure that there are no outstanding transactions in progress when we try to close the EntityManagerFactory.
So I'd like to extend ManagedRuntime with a findTransactionalBroker method that would allow the RegistryManagedRuntime to be more efficient, and put the current AbstractBrokerFactory's implementation into AbstractManagedRuntime.