Why aren't nested transactions supported by JTA? Is it because of the complexity of implementing them (which I doubt) or some design principle?
Why nested transactions are not supported in JTA
Asked Answered
There is a good article about nested transactions, JTA and XA: jbossts.blogspot.com/2009/03/nested-transaction-support.html –
Cardiganshire
I wonder if what I did will help you. Check it out here #14185203 –
Conducive
(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.)
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.
This may be in the spec but JTA's @Transactional annotation doesn't include
NESTED in the list of possible values. Although interestingly, Spring's @Transactional annotation does. –
Madiemadigan (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.)
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.
© 2022 - 2024 — McMap. All rights reserved.