英文:
Spring Chained Transaction Manager versus Atomikos
问题
Hi，我有一个分布式事务，我必须以某种方式来管理它们。
另外在 Spring 生态系统中，ChainedTransactionManager 可以做到这一点，另一方面在 Spring 文档中提到可以使用 Atomikos 来处理分布式事务。
https://docs.spring.io/spring-boot/docs/2.1.6.RELEASE/reference/html/boot-features-jta.html
我应该使用哪个？我更倾向于使用 Spring 库，但 Atomikos 比 Spring 事务管理器更强大吗？如果有人两者都使用，可以比较一下优缺点。
英文:
Hi I have a distributed transactions and I have to manage them somehow
Also in spring ecosystem ChainedTransactionManager can do that on the other hand in spring document Atomikos can be used for distributed transactions
https://docs.spring.io/spring-boot/docs/2.1.6.RELEASE/reference/html/boot-features-jta.html
Which one I should use?I prefer to stay in spring librarys but Atomikos is much more than spring transaction manager?If someone use them both,Can compare pros and cons
答案1
得分: 2
Sure, here's the translation:
使用 Atomikos 是一个更好的综合解决方案。ChainedTransactionManager 是一种在某些情况下可以使用的东西。它所做出的假设在 javadocs 中已经说明：
> PlatformTransactionManager 的实现，对事务的创建、提交和回滚进行编排，应用于一系列的委托。使用这个实现前提是导致事务回滚的错误通常会在事务完成之前或在最内部的 PlatformTransactionManager 提交期间发生。
>
> 配置的实例将按照给定的顺序启动事务，并以相反的顺序提交/回滚，这意味着最可能中断事务的 PlatformTransactionManager 应该是配置列表中的最后一个。在提交期间抛出异常的 PlatformTransactionManager 将自动导致其余事务管理器回滚，而不是提交。
使用 ChainedTransactionManager 仍然存在一个事务提交而另一个事务失败的可能性。
而使用 Atomikos 则是在两个数据库上进行真正的分布式事务，要么全部提交，要么全部回滚。但这也会产生一些后果，可能会影响应用程序的支持，例如当事务在一个数据库上完全提交并在另一个数据库上准备好时，此时应用程序崩溃。您需要确保您的应用程序能够从这种情况中恢复。通常情况下，当应用程序重新启动时，事务会在第二个数据库上完全提交，但可能不会发生。
那么哪种方案是正确的？这取决于情况。
英文:
Using Atomikos is a better overall solution. The ChainedTransactionManager is something you can use in some cases. The assumption it makes are stated in the javadocs:
> PlatformTransactionManager implementation that orchestrates transaction creation, commits and rollbacks to a list of delegates. Using this implementation assumes that errors causing a transaction rollback will usually happen before the transaction completion or during the commit of the most inner PlatformTransactionManager.
>
> The configured instances will start transactions in the order given and commit/rollback in reverse order, which means the PlatformTransactionManager most likely to break the transaction should be the last in the list configured. A PlatformTransactionManager throwing an exception during commit will automatically cause the remaining transaction managers to roll back instead of committing.
The chance of committing one transaction and the other one failing still remains with ChainedTransactionManager.
Using Atomikos is a real distributed transaction all or nothing on both databases. But this also has some consequences that can affect the support of the application, for example when the TX is fully commited on one DB and prepared on the other, and at that point the application crashes. You'll need to ensure that your application can recover from this scenario. Usually the TX would be fully commited on the second DB when the app is restarted, but that might not happen.
So which one is the right one? It depends.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论