如何解决JEE 中的 XA 或非 XA
我对这一段有疑问 “最初，所有事务都是本地的。如果非 XA 数据源连接是事务范围内登记的第一个资源连接，则当（第二个）XA 数据源连接加入它时，它将成为全局事务。如果第二个非XA 数据源连接尝试加入，抛出异常。” -> 链接 https://docs.oracle.com/cd/E19229-01/819-1644/detrans.html（全球和本地交易）。
-
如果第一个 ejb trans-type=required 在 db 上使用 XA 并使用 db non-xa 调用远程 EJB trans-type=required（部署在另一个应用程序服务器中）会发生什么？此刻我是否可以有两个不同的交易，以便 xa 不是正确的选择？如果两个 ejb 在同一个服务器但在两个不同的耳朵中会发生什么？
-
"在只有一个单阶段提交资源提供者参与事务并且所有参与事务的两阶段提交资源提供者都以只读方式使用的情况下. 在这种情况下，两阶段提交资源在两阶段提交的准备阶段都投票为只读。因为一阶段提交资源提供者是唯一完成任何更新的提供者，所以一阶段提交资源不会不必准备。” https://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.doc/ae/cjta_trans.html 只读是什么意思？那么我们可以将 xa 更新与 readonly non xa 混合使用吗？
解决方法
其中一些确实应该拆分为单独的问题。我可以回答前几个问题。
- 我可以拥有第一个非 XA 连接和第二个 XA 连接吗？
是的，如果您愿意使用 Last Participant Support
- 所以第一个变成 xa 没有抛出任何异常？
不，事务管理器无法将不支持 xa 的连接转换为支持 xa 的连接。将在连接上执行正常的非 xa 提交或回滚，但它仍然与 XA 资源一起参与事务。我将在总结最后参与者支持优化的过程中进一步讨论如何做到这一点。
- 我可以将第一个交易标记为 xa，第二个标记为 xa，第三个为非 xa 吗？
我假设您的意思是说第一个 连接 标记为 xa，依此类推。是的，您可以依靠 Last Participant Support
- 只读是什么意思？
只读是指以不修改任何数据的方式使用事务资源。例如，您可能会运行一个查询，锁定数据库中的一行并从中读取数据，但不对其执行任何更新。
- 所以我们可以将 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 的资源，使事务处于怀疑状态，需要手动干预才能正确恢复。只有在您愿意接受这种风险的情况下才启用/依赖最后参与者支持。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
