Why nested transactions are not supported in JTA

Question

Why aren't nested transactions supported by JTA? Is it because of the complexity of implementing them (which I doubt) or some design principle?

Answer 1

(As @Piotr Nowicki points out, JTA does allow nested transactions, but this is optional not mandatory.)

Why? This is one of those questions that is impossible to answer with any certainty, unless you were one of the people "in the room" when the decisions were made.

• It could be the inherent complexity of including nested transactions as part of the spec. Or apparent complexity at the time; i.e. they weren't sure they knew how to do a good job of specifying them.

• It could be that they thought there wasn't enough demand.

• It could be time pressure ... or just plain exhaustion.

• It could be "commercial reasons"; e.g. certain vendors not wanting to interfere with product launch schedules by expanding the scope of the spec.

But, the bottom line is that if you want the real answer, you would need to ask the people in the working group that wrote JTA specifications. (And I doubt they would tell you ... on the record.)

Answer 2

JTA specification is not saying that the it doesn't support the nested transactions - it just doesn't require the implementors to support it.

Following excerpts are taken from the JTA 1.1 spec:

p. 11, 13; 3.1 UserTransaction interface and 3.2 TransactionManager interface

"Support for nested tranactions is not required."

p. 13, 3.2.1 Starting a Transaction

"If the Transaction Manager implementation does not support nested transactions, the TransactionManager.begin method throws the NotSupportedException when the calling thread is already associated with a transaction."

There might be actually a problem with the XAResource that you might try enlisting with the current transaction (I believe it might be related with the X/Open XA specification):

3.4.4 Transaction Association

XAResource does not support nested transactions. It is an error for the XAResource.start method to be invoked on a connection that is currently associated with a different transaction.

Answer 3

Its neither the answer is business.

Many containers such as JBoss provide more complex alternative transaction managers which support concepts like nested transactions, but others like glassfish do not. Yet both of these are Java EE compliant. The idea is to keep the spec simple to lower the barrier of compliance for vendors.

Why force someone to implement a complex transaction manager that only covers .5% of transactional use cases or forgo Java EE compliance?

Nothing stops ambitious vendors from going above and beyond the specification, but they don't have the option to leave anything out.