Do conforming implementations of javax.transaction.Transaction
need to be thread safe?
Are implementations of this expected to handle concurrent requests from different threads?
As an example:
// Thread A
transaction.commit();
// Thread B, while that commit is still running
transaction.setRollbackOnly();
I am asking this question because I can see Infinispan interacting with the transaction manager in this way which results in a deadlock. I want to understand if this is a bug in Infinispan or the transaction manager.
JTA says, that:
§3.3 - Transaction Interface
The
Transaction.commit
andTransaction.rollback
methods allow the target object to be comitted or rolled back. The calling thread is not required to have the same transaction associated with the thread. If the calling thread is not allowed to commit the transaction, the transaction manager throws an exception.
Specification does not say anything more about this point; therefore, it is not required, pre se, that the vendor must provide a thread-safe implementation of javax.transaction.Transaction
.