JEE 中的 XA 或非 XA
XA or non XA in JEE
我对这一段有疑问
“最初，所有事务都是本地的。如果非 XA 数据源连接是事务范围内的第一个资源连接，则当（第二个）XA 数据源连接加入它时它将成为全局事务。如果第二个非 - XA 数据源连接尝试加入，抛出异常。” -> link https://docs.oracle.com/cd/E19229-01/819-1644/detrans.html（全局和本地事务）。
我可以有第一个连接非 XA 和第二个 XA 连接吗？那么第一个成为 xa 没有抛出任何异常？ （我有疑问）
我可以让第一笔交易标记为 xa，第二笔交易标记为 xa，第三笔交易未标记为 xa 吗？ （我想没有）
如果第一个 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 更新与只读非 xa 混合使用吗？
其中一些确实应该拆分成单独的问题。我可以回答前几个问题。
- Can I have the first connection non XA and the second XA?
可以，如果你愿意用Last Participant Support
- So the first become xa without any Exception thrown?
不，事务管理器无法将不支持 xa 的连接转换为支持 xa 的连接。正常的非 xa 提交或回滚将在连接上执行，但它仍然与 XA 资源一起参与事务。我将在总结 Last Participant Support 优化时进一步讨论这是如何完成的。
- Can I have fist transaction marked xa, second marked xa and third non xa?
我假设你是想说第一个 connection 标记为 xa，等等。是的，你可以依靠 Last Participant Support
- What mean for readonly ?
只读是指以不修改任何数据的方式使用事务资源。例如，您可能 运行 锁定数据库中的一行并从中读取数据但不对其执行任何更新的查询。
- So we can mix xa updates with readonly non xa?
你把这个反过来了。您引用的文档表明 XA 资源只能读取，非 xa 资源可以进行更新。这是有效的，因为 XA 资源有一种规范定义的方式来向事务管理器指示它们没有修改任何数据（通过在对 xa.prepare 请求的响应中投票 XA_RDONLY ）。因为他们没有写入任何数据，他们只需要释放他们的锁，所以整个事务的提交只是减少到单阶段资源的非xa commit/rollback 然后是xa-capable的任何一个解决方案资源（提交或回滚）会产生相同的效果。
上次参与者支持
前面提到的最后参与者支持是应用程序服务器的一项功能，它模拟非 xa 资源作为事务的一部分与一个或多个支持 xa 的资源一起参与。依赖此优化存在一些风险，即交易可能存在疑问的时间 window，需要人工干预来解决。
它是这样工作的：
您可以像往常一样对所有登记的资源（xa 和非 xa）进行操作，准备就绪后，您可以调用 userTransaction.commit 操作（或依靠容器管理的事务来发出为你承诺）。当事务管理器收到提交请求时，它看到涉及到非xa资源，并以特殊方式将prepare/commit操作命令到后端。首先，它告诉所有支持 xa 的资源执行 xa.prepare，并接收每个资源的投票。如果所有人都表明他们已成功准备并且能够提交，那么事务管理器将继续向非 xa 资源发出提交。如果非 xa 资源的提交成功，那么事务管理器将提交所有支持 xa 的资源。即使此时系统宕机，恢复日志中也写明了这些资源必须提交，事务管理器稍后会在恢复尝试中找到它们并提交，其在后端的相应记录将被锁定，直到那个会发生。如果非 xa 资源的提交失败，那么事务管理器将转而继续回滚所有支持 xa 的资源。这里的风险来自提交非 xa 能力资源的请求可能根本 return 的可能性，使事务管理器无法知道该资源是已提交还是已回滚，因此无法知道是提交还是回滚支持 xa 的资源，使事务处于不确定状态并且需要手动干预才能正确恢复。如果您可以接受此风险，则仅 enable/rely 在上次参与者支持时。
我对这一段有疑问 “最初，所有事务都是本地的。如果非 XA 数据源连接是事务范围内的第一个资源连接，则当（第二个）XA 数据源连接加入它时它将成为全局事务。如果第二个非 - XA 数据源连接尝试加入，抛出异常。” -> link https://docs.oracle.com/cd/E19229-01/819-1644/detrans.html（全局和本地事务）。
我可以有第一个连接非 XA 和第二个 XA 连接吗？那么第一个成为 xa 没有抛出任何异常？ （我有疑问）
我可以让第一笔交易标记为 xa，第二笔交易标记为 xa，第三笔交易未标记为 xa 吗？ （我想没有）
如果第一个 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 更新与只读非 xa 混合使用吗？
其中一些确实应该拆分成单独的问题。我可以回答前几个问题。
- Can I have the first connection non XA and the second XA?
可以，如果你愿意用Last Participant Support
- So the first become xa without any Exception thrown?
不，事务管理器无法将不支持 xa 的连接转换为支持 xa 的连接。正常的非 xa 提交或回滚将在连接上执行，但它仍然与 XA 资源一起参与事务。我将在总结 Last Participant Support 优化时进一步讨论这是如何完成的。
- Can I have fist transaction marked xa, second marked xa and third non xa?
我假设你是想说第一个 connection 标记为 xa，等等。是的，你可以依靠 Last Participant Support
- What mean for readonly ?
只读是指以不修改任何数据的方式使用事务资源。例如，您可能 运行 锁定数据库中的一行并从中读取数据但不对其执行任何更新的查询。
- So we can mix xa updates with readonly non xa?
你把这个反过来了。您引用的文档表明 XA 资源只能读取，非 xa 资源可以进行更新。这是有效的，因为 XA 资源有一种规范定义的方式来向事务管理器指示它们没有修改任何数据（通过在对 xa.prepare 请求的响应中投票 XA_RDONLY ）。因为他们没有写入任何数据，他们只需要释放他们的锁，所以整个事务的提交只是减少到单阶段资源的非xa commit/rollback 然后是xa-capable的任何一个解决方案资源（提交或回滚）会产生相同的效果。
上次参与者支持
前面提到的最后参与者支持是应用程序服务器的一项功能，它模拟非 xa 资源作为事务的一部分与一个或多个支持 xa 的资源一起参与。依赖此优化存在一些风险，即交易可能存在疑问的时间 window，需要人工干预来解决。 它是这样工作的：
您可以像往常一样对所有登记的资源（xa 和非 xa）进行操作，准备就绪后，您可以调用 userTransaction.commit 操作（或依靠容器管理的事务来发出为你承诺）。当事务管理器收到提交请求时，它看到涉及到非xa资源，并以特殊方式将prepare/commit操作命令到后端。首先，它告诉所有支持 xa 的资源执行 xa.prepare，并接收每个资源的投票。如果所有人都表明他们已成功准备并且能够提交，那么事务管理器将继续向非 xa 资源发出提交。如果非 xa 资源的提交成功，那么事务管理器将提交所有支持 xa 的资源。即使此时系统宕机，恢复日志中也写明了这些资源必须提交，事务管理器稍后会在恢复尝试中找到它们并提交，其在后端的相应记录将被锁定，直到那个会发生。如果非 xa 资源的提交失败，那么事务管理器将转而继续回滚所有支持 xa 的资源。这里的风险来自提交非 xa 能力资源的请求可能根本 return 的可能性，使事务管理器无法知道该资源是已提交还是已回滚，因此无法知道是提交还是回滚支持 xa 的资源，使事务处于不确定状态并且需要手动干预才能正确恢复。如果您可以接受此风险，则仅 enable/rely 在上次参与者支持时。