jdbc事务 jta事务
我最近发表了一篇有关如何将非事务性资源（如Web服务/微服务）绑定到全局分布式事务中的文章，以便自动处理恢复。 多年来，我经常不得不将“非事务性”系统集成到Java EE应用程序服务器中，而数据一致性通常是讨论的话题，甚至是非功能性需求。 我将“非事务性”用引号引起来，因为通常系统包含确保数据一致性的方法，例如使用调用进行补偿，但是这些系统通常不是您传统上称为事务性的。 当然，无法将Java EE应用程序服务器配置为自动处理此类资源的恢复。
以下是我们编译的模式列表，显示了面对集成非事务系统的任务时保持一致性的不同方法。
- 将作业写入数据库 –常见的情况是您要在出售后向您发送一封电子邮件确认信。 您无法发送电子邮件，然后尝试将销售交易提交到数据库，因为如果提交失败，客户将收到一封电子邮件，指出他们已经购买了商品，并且您没有任何记录。 在将销售交易提交到数据库之后，您将无法发送电子邮件，因为如果电子邮件发送失败（例如，邮件服务器暂时关闭），则客户将无法获得其确认，也许会带有指向票证的链接他们买了。 一种解决方案是将需要发送电子邮件的事实写入持久销售的同一笔交易中。 然后，批处理或
@ScheduledEJB可以定期检查以查看是否应发送电子邮件。 成功发送电子邮件后，它将更改记录的状态，以便不再发送电子邮件。 同样的问题在这里适用，您可能只能发送电子邮件，而不能更新数据库。 但是，如果您能够读取数据库，则很可能能够对其进行更新，并且由于数据库故障而发送两次相同的电子邮件并不比从不发送邮件那样糟糕，就像您不这样做一样。处理异步发送电子邮件。 像这样进行集成的一个缺点是，这意味着您无法集成需要结果的系统，以便在答复用户之前继续处理业务逻辑。 您必须异步处理集成。 - JMS –在与以前的解决方案相似的场景中，您可以发送包含作业的JMS消息，而不是将作业写入数据库。 JMS是事务性的，但是是异步的，因此该解决方案具有与上述解决方案相同的缺点。 如果您当时无法处理工作，则无需更改待完成工作的状态，而是将消息发送到带有属性的队列中，以便仅在一定时间后处理该消息，或者发送消息发送到死信队列以进行手动处理。
- 通用连接器（JCA适配器） –我最近发表了一篇博客文章，描述了我创建的通用JCA资源适配器，它使您通常可以将非事务性资源（如Web服务）绑定到JTA事务中。 有关更多详细信息，请参见博客文章。 使用通用连接器意味着事务管理器将在需要提交，回滚或恢复事务时执行回调，因此您只需要编写响应这些事件的应用程序代码即可。
- CDI事件 –在字段和字段上使用
@Inject @Qualifier Event<T>field.fire(t);当您要在方法参数上触发事件＆@@Observes(during=TransactionPhase.AFTER_FAILURE) @Qualifier T时，在事务失败后，将为每个触发的事件调用该方法。 这样，您可以为事务失败时实施一些补偿。 同样，您可以使用不同的交易阶段来执行不同的操作，例如AFTER_SUCCESS来执行呼叫以确认初始预订。 我们甚至使用了这些机制来延迟对远程系统的调用，例如在提交之前将工作发布到工作流引擎，以便确保在远程系统调用完成之前，复杂过程中的所有验证逻辑都已完成。制作。 请参阅下面的数字12。 - 定制解决方案 –如果您真的可以证明其合理性，那么您可以构建带有超时等内容的复杂代码，其中包括批处理和脚本，这些批处理和脚本使用远程资源来处理提交，回滚和恢复事务。 您需要问自己的问题是您是编写业务代码的专家还是有效编写事务管理器的专家。
- 业务流程引擎 –现代引擎可以将各种远程资源集成到业务流程中，并且它们倾向于处理故障恢复之类的事情。 它们通常重试失败的呼叫，并且可以在远程系统再次变为联机状态期间持久地处理过程状态，以便可以恢复过程。 BPEL支持补偿以确保整个环境的一致性，而不是提交和回滚。
- Atomikos＆TCC –一种能够将Web服务绑定到JTA事务中的产品。 据我所知，它是一个独立的事务管理器，可以在Java EE应用程序服务器之外运行。 但是我没有这个产品的经验。
- WS-AT –使用专有配置（和/或注释），您可以设置两个应用程序服务器以在全局事务中完成其工作。 虽然这听起来很有希望，但我还没有遇到实现WS-AT的高效系统。 尽管JBoss正在准备支持REST服务的管道 ，但实际上仅支持SOAP Web服务。
- EJB –远程EJB：Java EE应用服务器能够在较长时间内将事务上下文从一台服务器传播到另一台服务器。 如果您需要调用恰巧是使用Java EE堆栈实现的服务，为什么不使用远程EJB而不是通过Web服务调用它来进行调用，以便将服务免费绑定到全局事务中呢？
–本地EJB：如果您要调用的服务恰好是使用EJB技术用Java编写的，为什么不只是在本地部署它，而不是花更多的精力通过SOAP Web服务远程调用它呢？ 您可能会从企业架构师那里获得布朗尼点，但是可扩展性和可组合性是否已与性能，一致性和简单性进行了比较？ 当然，具有微服务等趋势的现代体系结构意味着部署大量远程服务是好的，但是总要权衡取舍，在决定需要远程访问景观的哪些部分时，您需要真正理解它。 - 事务回调 –与解决方案4类似，但使用事务同步 API注册在事务相关阶段调用的回调。 与CDI事件不同，这里的问题是您不知道在其中提交或回滚事务的上下文，因为不像在CDI中传递给观察方法的对象那样，回调没有传递相关数据。 。 因此，如果您需要补偿交易并致电说一个Web服务来取消您在交易过程中所做的事情，那么您将在何处获得所需的数据呢？
- 将XA资源注册到事务中 –添加XAResource接口的自定义实现，您可以使用
enlistResource方法将其enlistResource到事务中。 不幸的是，commit / rollback方法仅被调用一次，如果它们失败了，在恢复过程中将不会被再次调用。 - 最后是非事务性资源 -如果无法实现其他模式，并且您不需要在流程中的特定时间调用资源，例如，您需要发送电子邮件作为交易的一部分，但是不需要不管您是在第一步还是最后一个步骤中执行此操作，都必须始终在处理结束时（即在提交事务之前）立即调用它。 与远程系统调用失败的机会相比，事务无法提交的机会相对较小（特别是如果所有SQL已刷新到数据库中的情况）。 如果调用失败，则回滚事务。 如果调用成功，则提交事务。 如果事务然后在提交过程中失败，并且对您补偿非事务性资源很重要，那么您将需要使用上述模式之一向系统添加一些补偿。
下表总结了解决方案。 恢复列指示此解决方案支持的自动恢复级别。 同步性栏指示如果需要响应以继续处理，是否可以使用解决方案，在这种情况下，您需要同步解决方案。 这里的同步与阻塞与非阻塞无关，而是与计时以及是否需要响应才能完成活动的处理有关。
| 解 | 同步性 | 复苏 |
|---|---|---|
| 1）将作业写入数据库 | 异步 | 手册1 |
| 2）JMS | 异步 | 半自动2 |
| 3）通用连接器（JCA适配器） | 同步 | 自动3 |
| 4）CDI活动 | 异步 | 不支持4 |
| 5）定制解决方案 | 取决于您的实现 | 取决于您的实现 |
| 6）业务流程引擎 | 同步 | 支持5 |
| 7）Atomikos和TCC | 没有经验，大概是同步的 | 没有经验，大概支持 |
| 8）WS-AT（配置） | 没有经验，大概是同步的 | 没有经验，大概支持 |
| 9）EJB | 同步 | 自动6 |
| 10）交易回调 | 同步 | 不支持4 |
| 11）招募XA资源进行交易 | 同步 | 不支持4 |
| 12）非交易资源排在最后 | 异步，因为必须最后调用 | 不支持 |
脚注：
- 手动恢复–您需要编程处理失败时应采取的措施，即在将工作置于“死信队列”之前，应尝试重试的频率。
- 如果将队列配置为持久性，JMS将自动尝试重新发送消息。 但是，程序员尝试处理失败的消息将由您自己决定。
- 事务管理器将不断尝试提交/回滚未完成的事务，直到管理员介入以处理长时间运行的故障为止。
- 回调仅被调用一次，因此您只有一次机会
- 业务流程引擎将反复尝试重新调用失败的Web服务调用。 补偿也是如此。 该行为通常是可配置的。
- 远程EJB：JTA事务跨其他应用服务器传播，因此协调事务管理器会将事务恢复传播到绑定到该事务的其他应用服务器。
本地EJB：使用本地EJB意味着它们对数据库的任何调用都将在与应用程序代码相同的事务中处理。 如果本地EJB使用其他数据库，则应对所有数据库，消息队列等使用XA驱动程序，以便事务管理器可以使用两阶段提交来确保系统范围的一致性。
在所有这些中，我目前最喜欢的是通用连接器 。 它支持需要响应的呼叫以及完全自动的恢复。 这意味着我可以专注于编写业务代码，而不是真正属于框架的样板代码。
如果您知道其他方法，请与我联系或发表评论，以便我可以将它们添加到列表中。
翻译自: https://www.javacodegeeks.com/2015/08/several-patterns-for-binding-non-transactional-resources-into-jta-transactions.html
jdbc事务 jta事务
