This PR removes usage of the java.util.concurrent.ConcurrentHashMap class in LocalXAResource to avoid thread pinning issues (ConcurrentHashMap uses synchronized internally, and association computation involves IO).
This initial revision of this PR is as simple as can be at the possible expense of too coarse a lock, serializing all access to the associations Map through a single ReentrantLock.
In the normal JTA course of events this should probably be fine? It is worth bearing in mind that a JTA implementation can conceivably perform any association-mutating operation on a given thread-specific transaction branch from any thread, which makes things tricky.
Because of that, I plan to immediately and subsequently explore doing this in a more performant way in a subsequent revision, but this PR will exist so that if it is deemed necessary to push it as-is we can do so. I don't know offhand whether this will help or hurt overall performance.
This PR removes usage of the
java.util.concurrent.ConcurrentHashMapclass inLocalXAResourceto avoid thread pinning issues (ConcurrentHashMapusessynchronizedinternally, and association computation involves IO).This initial revision of this PR is as simple as can be at the possible expense of too coarse a lock, serializing all access to the associations
Mapthrough a singleReentrantLock.In the normal JTA course of events this should probably be fine? It is worth bearing in mind that a JTA implementation can conceivably perform any association-mutating operation on a given thread-specific transaction branch from any thread, which makes things tricky.
Because of that, I plan to immediately and subsequently explore doing this in a more performant way in a subsequent revision, but this PR will exist so that if it is deemed necessary to push it as-is we can do so. I don't know offhand whether this will help or hurt overall performance.