【问题标题】:XA or non XA in JEEJEE 中的 XA 或非 XA
【发布时间】:2021-04-17 05:20:04
【问题描述】:

我对这一段有疑问 “最初,所有事务都是本地的。如果非 XA 数据源连接是事务范围内登记的第一个资源连接,那么当(第二个)XA 数据源连接加入它时,它将成为全局事务。如果第二个非 XA 数据源连接是XA 数据源连接尝试加入,抛出异常。” -> 链接https://docs.oracle.com/cd/E19229-01/819-1644/detrans.html(全球和本地交易)。

  1. 我可以有第一个非 XA 连接和第二个 XA 连接吗?那么第一个变成 xa 没有任何异常抛出? (我有疑问)

  2. 我可以将第一笔交易标记为 xa,第二笔交易标记为 xa,第三笔交易标记为非 xa 吗? (我想没有)

  3. 如果第一个 ejb trans-type=required 在 db 上使用 XA 并使用非 xa 的 db 调用远程 EJB trans-type=required(部署在另一个应用程序服务器中)会发生什么?此刻我是否可以进行两次不同的交易,以使 xa 不是正确的选择?如果两个 ejb 在同一台服务器中但在两个不同的耳朵中会发生什么?

  4. “在只有一个单阶段提交资源提供者参与事务并且所有参与事务的两阶段提交资源提供者都以只读方式使用的场景中。在此在这种情况下,两阶段提交资源在两阶段提交的准备阶段都投票只读。因为一阶段提交资源提供者是唯一完成任何更新的提供者,所以一阶段提交资源不必做好准备。” https://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.doc/ae/cjta_trans.html 对 readonly 意味着什么?所以我们可以混合 xa 更新和只读非 xa 吗?

【问题讨论】:

    标签: java-ee-6 websphere-8 websphere-7 xa java-ee-5


    【解决方案1】:

    其中一些确实应该分成单独的问题。我可以回答前几个问题。

    1. 我可以让第一个非 XA 连接和第二个 XA 连接吗?

    是的,如果你愿意使用Last Participant Support

    1. 那么第一个变成 xa 没有任何异常抛出?

    不,事务管理器无法将不支持 xa 的连接转换为支持 xa 的连接。将在连接上执行正常的非 xa 提交或回滚,但它仍然与 XA 资源一起参与事务。在总结 Last Participant Support 优化时,我将进一步讨论如何做到这一点。

    1. 我可以将第一笔交易标记为 xa,第二笔交易标记为 xa,第三笔交易标记为非 xa 吗?

    我假设你的意思是说第一个 connection 标记为 xa,依此类推。是的,你可以依靠Last Participant Support来做到这一点

    1. 只读是什么意思?

    只读是指以不修改任何数据的方式使用事务资源。例如,您可能会运行一个查询,该查询会锁定数据库中的一行并从中读取数据,但不会对其执行任何更新。

    1. 所以我们可以将 xa 更新与只读非 xa 混合使用?

    你有这个相反的。您引用的文档表明 XA 资源可以只读,非 xa 资源可以进行更新。这是因为 XA 资源有一种规范定义的方式向事务管理器指示它们没有修改任何数据(通过在它们对 xa.prepare 请求的响应中投票 XA_RDONLY)。因为他们没有写任何数据,他们只需要释放他们的锁,所以整个事务的提交只是减少到单阶段资源的非xa提交/回滚,然后是xa-capable资源的解析(提交或回滚)将具有相同的效果。

    最后参与者支持

    前面提到的最后参与者支持是应用程序服务器的一项功能,它模拟非 xa 资源作为事务的一部分与一个或多个支持 xa 的资源一起参与。依赖这种优化存在一些风险,即交易可能处于不确定状态的时间窗口,需要人工干预才能解决。 以下是它的工作原理:

    您像往常一样对所有征用资源(xa 和非 xa)进行操作,当您准备好时,您调用 userTransaction.commit 操作(或依赖容器管理的事务为您发出提交) .当事务管理器收到提交请求时,它会看到涉及到一个非 xa 资源,并以一种特殊的方式将准备/提交操作命令到后端。首先,它告诉所有支持 xa 的资源来做 xa.prepare,并从他们每个人那里获得投票。如果所有都表明他们已经成功准备并且能够提交,那么事务管理器继续向非 xa 资源发出提交。如果非 xa 资源的提交成功,则事务管理器提交所有支持 xa 的资源。即使此时系统宕机,在恢复日志中也会写入这些资源必须提交的内容,事务管理器稍后会在恢复尝试期间找到它们并提交它们,它们在后端的相应记录被锁定,直到那个会发生。如果非 xa 资源的提交失败,则事务管理器将继续回滚所有支持 xa 的资源。这里的风险来自提交不支持 xa 的资源的请求可能根本不会返回,使事务管理器无法知道该资源是否已提交或回滚,因此无法知道是提交还是回滚。回滚支持 xa 的资源,使事务处于不确定状态,需要手动干预才能正确恢复。如果您可以接受此风险,请仅启用/依赖最后参与者支持。

    【讨论】:

    • 好的,非常感谢! 1)所以我们可以混合xa和非xa当且仅当xa是只读的,对吗?仅当 xa 和非 xa 都是在 db 或其他资源上更新的事务时才需要 LPS。.2) 那么这是否涉及任何类型的资源,如 JMS 或 MQ 队列? 3)如果两个ejb部署在不同的ear或不同的was服务器,如果它们使用单​​个db资源或非XA资源,它们仍然需要XA?
    • 4)如果它们部署在不同的服务器上,事务传播on(都用trans type = required注解),第二个ejb称为打开一个新事务或使用第一个ejb的传播(因为必需)在远程 ejb 服务器中?谢谢
    • 拥有只读 xa 资源是进一步优化,而不是 LPS 的要求。无论资源是否为只读,都可以使用 LPS。使用 LPS 的决定更多的是一个问题,即您是否愿意接受不确定事务的风险,并面临是否提交或回滚更新以解决它的决定。就资源类型而言,JMS 连接工厂(包括队列连接工厂)可以是支持 xa 的资源。对于 EJB 的问题,请使用单独的 StackOverflow 问题,也许其他人可以回答。
    猜你喜欢
    • 2014-02-06
    • 1970-01-01
    • 1970-01-01
    • 2019-06-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-05-01
    • 1970-01-01
    相关资源
    最近更新 更多