JtaTransactionManager和ChainedTransactionManager之间的区别？

正如文档所说：ChainedTransactionManger doc：

PlatformTransactionManager 实现，用于协调事务创建、提交和回滚到委托列表。使用此实现假定导致事务回滚的错误通常发生在事务完成之前或最内部的 PlatformTransactionManager 的提交期间。配置的实例将按给定的顺序启动事务，并以相反的顺序提交/回滚，这意味着最有可能破坏事务的平台事务管理器应该是配置列表中的最后一个。平台事务管理器在提交期间引发异常将自动导致剩余的事务管理器回滚而不是提交。

这意味着您可以通过向其传递多个事务管理器来创建一个链式事务管理器。如果一个事务管理器发生异常，将按照指定它们的反顺序为所有事务管理器生成回滚

JtaTransactionManager doc：

PlatformTransactionManager 实现 JTA，委托给后端 JTA 提供程序。这通常用于委托给 Java EE 服务器的事务协调器，但也可以使用嵌入在应用程序中的本地 JTA 提供程序进行配置。此事务管理器适用于处理分布式事务，即跨多个资源的事务，以及通常用于控制应用程序服务器资源（例如 JNDI 中可用的 JDBC 数据源）上的事务。例如，对于单个 JDBC 数据源，DataSourceTransactionManager 是完全足够的，对于使用 Hibernate 访问单个资源（包括事务性缓存），HibernateTransactionManager 是合适的。

可以使用此事务管理器来管理多个资源的分布式事务

这两个事务管理器都适合与多个资源一起使用，但是 JTA 事务管理器提供了严格的保证，即它将提交所有资源或不提交任何资源。它使用XA协议通过2PC（两阶段提交）来实现它。由于这是一种保持资源同步的复杂方法，因此会以性能为代价。

相反，ChainedTransactionManager不使用2PC和XA，它更像是一种声明应该以特定（反向）顺序提交或回滚多个资源的方式。像JTA事务管理器一样，它尝试将所有资源一起提交或回滚，但它并不能保证（所有提交或全部回滚）。然而，在特定情况下，这是完全没问题的。假设两个资源与链接的事务管理器一起使用：JMS 相关和数据库相关，以便在事务期间，您首先从队列中读取消息，然后处理一些涉及 DB 的业务逻辑，最后提交这两个资源。如果首先提交 DB，然后提交 JMS，则 DB 可能会提交，但 JMS 会回滚。在这种情况下，初始消息将留在消息队列中，这并不完全正常，并且可能导致重复的消息处理（因为消息已被处理并导致数据库提交成功）。但是，如果您的业务逻辑已为此做好准备，则可以处理这种情况 - 当然，这需要额外的代码来实现这种情况。但是，如果性能更重要，这是一个合理的交易，因为ChainedTransactionManager应该比JTA执行得快得多。

铌。与 ChainedTransactionManager 一起使用的事务管理器的顺序很重要：最有可能破坏事务的事务管理器应该是配置列表中的最后一个。

底线。如果您可以安全地处理一个资源提交而另一个资源回滚的情况，或者这种情况很少发生，因此您可以忽略它，那么您可以先尝试使用 ChainedTransactionManager。如果性能不是那么重要，并且/或者你想绝对确保多个资源同步，那么可能你应该使用JTA。