Static code analysis: nondeterministic locking behavior at ThreadAssociations#removeAll

Static code analysis category: Nondeterministic locking behavior

CID-17602: Bad choice of lock object - Nondeterministic locking behavior
in class `ThreadAssociations` [1] at method `removeAll`. There is used synchronized block
where lock is acquired at `globalTxAssociations` and `txAssociations`.

The problem (one for txAssociations is described as)
lock_acquire: Acquiring lock `com.arjuna.ats.jts.extensions.`ThreadAssociations.txAssociations`.
lock_on_assigned_field: Locking on the object referenced by field `ThreadAssociations.txAssociations`. This lock acquisition may race with another thread assigning to this field. The contents of `ThreadAssociations.txAssociations` may change while a thread is inside the critical section, allowing two threads to enter the critical section simultaneously.

• Instead of using `ThreadAssociations.txAssociations` as a lock, create a final field of type Object which is only used as a lock.
  assign_to_field: The expression `ThreadAssociations.txAssociations = null` assigns a new value to `ThreadAssociations.txAssociations`, a field whose contents are used as a lock. The locking behavior of this function may allow this assignment to occur multiple times.

Tom's reaction on this

I think that the bug is that there is any synchronization at all on txAssociations because it looks to be indexed by Thread.currentThread().

[1] https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/jts/extensions/ThreadAssociations.java#L125