为什么 JTA 不支持嵌套事务？是因为实现它们的复杂性（我对此表示怀疑）还是某些设计原则？
【问题讨论】：
标签： java jakarta-ee transactions jta nested-transactions
JTA 规范并不是说它不支持嵌套事务 - 它只是不要求实现者支持它。
以下摘自 JTA 1.1 规范：
p。 11、13； 3.1 UserTransaction 接口和3.2 TransactionManager 接口
“不需要支持嵌套事务。”
p。 13、3.2.1 开始交易
"如果事务管理器实现不支持嵌套事务，则 TransactionManager.begin 方法抛出 NotSupportedException 时 调用线程已与事务关联。”
XAResource 实际上可能存在问题，您可能会尝试在当前事务中登记（我相信它可能与 X/Open XA 规范有关）：
3.4.4 事务关联
XAResource 不支持 嵌套事务。这是一个错误 在当前关联的连接上调用 XAResource.start 方法 使用不同的交易。
【讨论】：
NESTED。虽然有趣的是，Spring 的@Transactional 注解does。
（正如@Piotr Nowicki 指出的那样，JTA 确实允许嵌套事务，但这是可选的而非强制性的。）
为什么？这是无法确定回答的问题之一，除非您是做出决定时“在场”的人之一。
这可能是在规范中包含嵌套事务的固有复杂性。或者当时明显的复杂性；即，他们不确定自己知道如何做好指定它们的工作。
可能是他们认为需求不足。
可能是时间压力……或者只是精疲力竭。
可能是“商业原因”；例如某些供应商不想通过扩大规范范围来干扰产品发布计划。
但是，底线是，如果您想要真正的答案，您需要询问编写 JTA 规范的工作组中的人员。 （而且我怀疑他们会告诉你……记录在案。）
【讨论】：
答案都不是生意。
JBoss 等许多容器提供了更复杂的替代事务管理器，它们支持嵌套事务等概念，但 glassfish 等其他容器不提供。然而，这两者都符合 Java EE。这样做的目的是使规范保持简单，以降低供应商的合规障碍。
为什么要强制某人实施仅涵盖 0.5% 事务用例的复杂事务管理器或放弃 Java EE 合规性？
没有什么能阻止雄心勃勃的供应商超越规范，但他们无法选择遗漏任何内容。
【讨论】：