3.2.2 Completing a Transaction
The TransactionManager.commit method completes the transaction currently
associated with the calling thread. After the commit method returns, the calling thread is not associated with a transaction.
If the commit method is called when the thread is
not associated with any transaction context, the TM throws an exception. In some
implementations, the commit operation is restricted to the transaction originator only.
If the calling thread is not allowed to commit the transaction, the TM throws an
exception.
The TransactionManager.rollback method rolls back the transaction associated
with the current thread. After the rollback method completes, the thread is associated with no transaction.

And the following block about Transaction (note there's no thread-tx disassociation clause)

3.3.3 Transaction Completion
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.

Unfortunately JOTM always disassociated the current thread and transaction and commit, which basically means one will never have a transaction in the COMMITTED state (it will always be gone, i.e. null). This comes from the fact there are no provisions for TX recovery in this implementation.

Everything stated above resulted in javax.transaction.NotSupportedException thrown at runtime with a hint to a nested transaction begin attempt. Unfortunately, tests have never caught it, but TMs like Websphere's or Arjuna did detect and reported this behavior.