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