JEE中的XA或非XA

Question

我对这一段有疑问：“最初，所有事务都是本地的。如果非XA数据源连接是在事务范围中登记的第一个资源连接，则当(第二个)XA数据源连接加入它时，它将成为一个全局事务。如果第二个非XA数据源连接试图加入，则会引发异常。”-> link https://docs.oracle.com/cd/E19229-01/819-1644/detrans.html ()。

1. 我能要第一个连接的非XA和第二个XA吗？所以第一个变成xa没有任何例外抛出？(我怀疑)
2. 我可以有第一个交易标记xa，第二个标记xa和第三个非xa？(我想没有)
3. 如果第一个ejb trans=required在db上使用XA并使用db非xa调用远程=required(部署在另一个应用服务器中)，会发生什么？在这个时刻，我可以有两个不同的事务，所以xa不是正确的选择吗？如果两个ejb位于同一个服务器，但位于两个不同的ear中，会发生什么？
4. “在只有一个单阶段提交资源提供程序参与事务的情况下，参与事务的所有两阶段提交资源提供程序都以只读方式使用。在这种情况下，两阶段提交资源都在两阶段提交的准备阶段投票只读。因为一阶段提交资源提供程序是唯一完成任何更新的提供者，因此一阶段提交资源不必准备。”trans.html对只读意味着什么？所以我们可以混合xa更新和只读非xa吗？

Answer 1

这些问题中的一些确实应该被分成不同的问题。我可以回答前几个问题。

1. 我能要第一个连接的非XA和第二个XA吗？

是的，如果你愿意使用最后一次参与者支助

1. 所以第一个变成xa没有任何例外抛出？

不，事务管理器不能将非xa功能的连接转换为具有xa能力的连接。正常的非XA提交或回滚将在连接上执行，但它仍然与XA资源一起参与事务。在总结最后一个参与者支持优化时，我将进一步讨论如何做到这一点。

1. 我可以有第一个交易标记xa，第二个标记xa和第三个非xa？

我想您的意思是第一个连接标记为xa，等等。是的，您可以依靠最后一次参与者支助来完成这个任务。

1. 只读意味着什么？

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

1. 所以我们可以混合xa更新和只读非xa吗？

你把这个倒过来了。您引用的文档表明XA资源可以只读，而非xa资源可以进行更新。这是因为XA资源有一种规范定义的方式，可以向事务管理器指示它们没有修改任何数据(在响应xa.prepare请求时投票给xa.prepare)。因为他们没有写任何数据，所以他们只需要释放锁，所以整个事务的提交只会减少到单阶段资源的非xa提交/回滚，那么支持xa的资源的解析(提交或回滚)就会产生同样的效果。

最后一位参与者支持

前面提到的最后一个参与者支持是应用服务器的一个特性，它模拟一个非xa资源与一个或多个具有xa功能的资源一起作为事务的一部分参与。依赖这种优化涉及到一些风险，即事务可能被怀疑的时间窗口，需要手动干预来解决它。以下是它的工作原理：

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