【问题标题】:Difference between JtaTransactionManager and ChainedTransactionManager ?JtaTransactionManager 和 ChainedTransactionManager 之间的区别?
【发布时间】:2015-10-18 20:24:51
【问题描述】:
我需要管理我的应用程序中的多个资源,例如 jms 和 database
在查看可以管理多个资源的事务管理器时,我遇到了 2 个事务管理器 JtaTransactionManager 和 ChainedTransactionManager,它们几乎声称他们可以管理多个资源。
谁能解释它们的主要区别是什么?我什么时候应该使用哪一个?
【问题讨论】:
标签:
java
spring
transactions
spring-transactions
【解决方案1】:
如文档所述:
ChainedTransactionManger doc:
PlatformTransactionManager 实现,用于协调事务创建、提交和回滚到委托列表。使用此实现假定导致事务回滚的错误通常发生在事务完成之前或最内部的 PlatformTransactionManager 提交期间。
配置的实例将按照给定的顺序启动事务,并以相反的顺序提交/回滚,这意味着最有可能中断事务的 PlatformTransactionManager 应该是配置列表中的最后一个。在提交期间抛出异常的 PlatformTransactionManager 将自动导致剩余的事务管理器回滚而不是提交。
这意味着您可以通过向其传递多个事务管理器来创建 ChainedTransactionManager。如果一个事务管理器发生异常,则会按照指定的相反顺序为所有事务管理器生成回滚
JtaTransactionManager doc:
JTA 的 PlatformTransactionManager 实现,委托给后端 JTA 提供者。这通常用于委托给 Java EE 服务器的事务协调器,但也可以使用嵌入在应用程序中的本地 JTA 提供程序进行配置。
该事务管理器适用于处理分布式事务,即跨越多个资源的事务,以及控制应用程序服务器资源(例如 JNDI 中可用的 JDBC 数据源)上的事务。对于单个 JDBC 数据源,DataSourceTransactionManager 就足够了,例如,对于使用 Hibernate 访问单个资源(包括事务缓存),HibernateTransactionManager 是合适的。
您可以使用此事务管理器来管理多个资源的分布式事务
【解决方案2】:
这两个事务管理器都适合与多个资源一起使用,但是 JTA 事务管理器提供了严格的保证,即它要么提交所有资源,要么不提交所有资源。它使用 XA 协议通过 2PC(两阶段提交)实现它。由于这是一种保持资源同步的复杂方法,因此会以性能为代价。
相反,ChainedTransactionManager 不使用 2PC 和 XA,它更多地只是一种声明多个资源应该以特定(反向)顺序一起提交或回滚的方式。与 JTA 事务管理器一样,它尝试将所有资源一起提交或回滚,但它不能保证(全部提交或全部回滚)。但是在特定情况下,它完全没问题。
假设两个资源与链式事务管理器一起使用:JMS 相关的和 DB 相关的,因此在事务期间,您首先从队列中读取消息,然后处理一些涉及 DB 的业务逻辑,最后提交这两个资源。如果先提交 DB,然后再提交 JMS,则 DB 可能提交但 JMS 回滚。在这种情况下,初始消息将留在消息队列中,这并不完全正常,并且可能导致重复的消息处理(因为消息已被处理并导致成功的 DB 提交)。但是,如果您的业务逻辑为此做好了准备,您就可以处理这种情况——当然要付出额外的代码来实现它。但是,如果性能更重要,这是一个合理的交易,因为 ChainedTransactionManager 的执行速度应该比 JTA 快得多。
注意。与 ChainedTransactionManager 一起使用的事务管理器的顺序很重要:最有可能破坏事务的事务管理器应该是配置列表中的最后一个。
底线。如果您可以安全地处理一个资源提交而另一个资源回滚的情况,或者这种情况很少发生,因此您可以忽略它,那么您可以先尝试使用 ChainedTransactionManager。
如果性能不是那么重要和/或您希望绝对确保多个资源同步,那么您可能应该使用 JTA。