我希望编写一个事务管理器，该事务管理器支持多数据库和尽力而为的提交逻辑。我应该基于Spring的AbstractPlatformTransactionManager或javax.transaction.TransactionManager还是其他的东西吗？
我有一些使用Spring的JpaTransactionManager和DataSourceTransactionManager以及内部自定义CustomCustomactionManager的应用程序。
我的目标是为我所有的Java应用程序提供一个事务管理器，以便我可以提供/控制常见的事务功能。 我的要求不是2PC，但我需要尽最大努力提交来提供多数据源支持（事务管理器通知应用程序提交失败，并且有责任通过重试失败的查询来处理这种情况）。
我一直在阅读有关Spring的PlatformTransactionManager，其实现Jpa和数据源事务管理器的信息。
SimpleJta中提供的经过检查的JTA / XA实现基于Javax.transaction.xa包类。
当我认为需要与现有应用程序轻松集成时，Spring的AbstractPlatformTransactionManager看起来像是新事务管理器的良好基础类。
另一方面，javax.transaction.xa包提供了一些简单的抽象来管理事务中的连接资源。也许我可以使用javax.transaction来实现单阶段提交，那么它将起作用。
我的问题是：使用Spring框架的AbstractPlatformTransactionManager更好还是使用javax.transaction并将其与Spring应用程序集成会更好？
我希望编写易于集成的组件（与现有的基于Spring的应用程序一起使用），简单且可维护的组件。
如果问题过于模糊，我们深表歉意。我仍在阅读选项，可能对Spring和javax.transaction并不完全了解。
答案 0 :(得分：0)
如果您需要保证应用程序的事务将在中断（包括服务器崩溃）后恢复，那么Full XA是您唯一的选择。在这种情况下，用于同步事务的共享资源是一个特殊的事务管理器，它使用XA协议协调有关流程的信息。在Java中，从开发人员的角度来看，该协议是通过JTA UserTransaction公开的。
如果应用程序启用了Spring，则它将使用Spring JtaTransactionManager和Spring声明式事务管理来隐藏基础同步的详细信息。对于开发人员来说，使用XA和不使用XA的区别在于，它配置工厂资源：DataSource实例和应用程序的事务管理器。 DataSource实例和事务管理器是应用程序中唯一XA或JTA特定的元素。
请参阅具有多个数据源的这种常规事务回滚，这将使您更加了解带有和不带有XA（https://www.javaworld.com/article/2077963/distributed-transactions-in-spring--with-and-without-xa.html）的分布式事务Spring
答案 1 :(得分：0)
我希望编写一个支持多数据库和尽力而为的提交逻辑的事务管理器。
有很多理由说明为什么这不是常见的事情。您可能不应该尝试使它成为事物，直到您了解它们是什么。
如果您需要保证应用程序的事务将在中断（包括服务器崩溃）后恢复，那么Full XA是您唯一的选择。
那是...错。的确，您需要完整的 ACID 保证，那么XA几乎是涉及数据库的可互操作tx的唯一选择。但是例如对于基于Web的资源管理器，WS-AT是一种非常好的ACID事务协议。
ACID交易并不是全部。对于saga类型的事务，您需要某种形式的补偿框架，该框架为应用程序提供生命周期回调。 WS-BA和最新的微型LRA规范在该领域工作。
因此，您的选择大致是：（mis）use XA with例如最后一个资源提交优化，多个最后一个资源或其他削弱的保证，并希望JTA API具有足够的灵活性，或者只是直接跳转到针对该工作量身定制的基于传奇的tx API。
我希望编写……简单且可维护的组件。
无论选择哪种交易模型，都不要尝试从头开始编写自己的交易管理器。分布式事务协调到处都是棘手的情况，而构建一个正确而强大的引擎要比初看起来要困难得多。而是利用现有的成熟的开源交易管理器之一。
Narayana开箱即用提供完整的ACID XA，但如果您确实需要，可以将其配置为在JTA API下提供最大的努力。 （提示：您没有。）如果您愿意采用WS-BA和LRA规范，它还具有传奇支持。在完整的JakaraEE应用服务器之外，唯一具有可比功能的可信竞争对手是Atomikos。 Spring本身不是分布式事务管理器实现，而是一个委托给它的API。