Do implementations of interface javax.transaction.Transaction need to be thread safe?

Question

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.

Answer 1

JTA says, that:

§3.3 - Transaction Interface

The Transaction.commit and Transaction.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.