XA 数据源 1PC 优化

Question

我正在使用 JBoss EAP 6.4 (Java EE 6)，我有一个关于应用程序服务器处理 XA 数据源（通过 EJB/JTA）的方式的问题，如果始终使用 2 阶段提交 (2PC)，或者如果应用 "optimization"。

假设我有这个：

@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class MyEjb {
   @EJB
   private MyFirstEjb first;

   @EJB
   private MySecondEjb second;

   // Transactional processing
   public void process() {
      first.processJpaStuff();
      second.processJpaStuff();
   }
}

假设:

MyFirstEjb 使用 XA 数据源 1 进行 JPA 查询。
MySecondEjb 使用 XA 数据源 2 进行 JPA 查询。

我正在使用 XA 数据源，因为这些 EJB 可用于需要 2PC 的其他情况（以及另一个数据源或 JMS 提供程序）。

我现在想分清几种情况：

MyFirstEjb 和 MySecondEjb 部署在同一个应用程序 (EAR) 中
MyFirstEjb 和 MySecondEjb 部署在同一应用程序服务器内的不同应用程序 (EAR) 中
MyFirstEjb 和 MySecondEjb 部署在不同的应用程序服务器中

及子案例：

a) XA 数据源 1 = XA 数据源 2

b) XA 数据源 1 != XA 数据源 2（同一数据库）

c) XA 数据源 1 != XA 数据源 2（不同的数据库）

我想 b) 和 c) 的管理方式相同。有一个全局事务，每个数据源都与 XA 事务管理器协作。应用了2PC。

案例 1.a) 和 2.a) 呢？由于两者最终都使用相同的数据源，我想是否存在某种不需要处理全局 2PC 事务的优化？如果是，是否有官方 (JTA / JBoss / ...) link 对此进行解释？所有应用程序服务器/实现都是一样的吗？

谢谢

Answer 1

1.MyFirstEjb 和 MySecondEjb 部署在同一应用程序 (EAR)

当数据源不同时，您可能知道，如果驱动程序和底层数据源无法加入全局事务，或者如果驱动程序未配置为加入全局事务，您将收到特定错误。

对于其他情况，除此之外，理想的场景是业务层处理两个数据源，所有客户端都处理业务层（应该完全避免不同的应用程序处理相同的数据源）。这就是可能发生的情况。

2.MyFirstEjb 和 MySecondEjb 部署在同一应用程序服务器中的不同应用程序 (EAR) 中

如果部署在同一个应用服务器上，但使用不同的.ear，客户端通过远程接口访问它们，因此每个启动一个完全不同的thread/transaction (REQUIRES_NEW)。如果出现问题，客户端将得到一个 EJBException。从客户端的角度来看，没有全局事务。

3.MyFirstEjb 和 MySecondEjb 部署在不同的应用程序服务器中

如果ejb 部署在不同的应用服务器上，同样适用。它们通过远程接口访问，因此它们各自开始一个新的交易。

Answer 2

视情况而定。

JTA（事务协调器）对 EJB 或应用程序一无所知。它只关注 XAResources 和关联的事务分支。正常情况是 JCA 管理 JPA 为实体 bean 使用的连接池，将为 JTA 提供每个使用的数据源一个 XAResource。 JTA 在相同的全局 tx id 下为每个分配不同的分支限定符。

在事务终止期间，JTA 准备每个 XAResource，此时优化开始。如果数据库引擎检测到同一个全局 tx 有多个分支 (connections/XAResources)，它可能 return 从第一个 XAResource 准备，但 READ_ONLY 从其余资源准备。假设 tx 结果只有一个 PREPARED 资源，其余都是只读的，那么它可以相应地优化终止的剩余部分。参见例如

http://narayana.io/docs/product/#two-phase-variants

https://docs.oracle.com/cd/B10501_01/java.920/a96654/xadistra.htm#1061004

请注意，根据供应商的不同，'db engine' 和 'database' 并不完全相同。一些系统将在同一台服务器上托管多个数据库并允许优化跨它们工作，而其他系统可能将每个数据库视为一个单独的事务引擎范围并且不优化此类情况。数据源也可能仅在用于连接的 userid/schema 上有所不同，依靠 permissions/schema 命名空间来隔离应用程序，而不需要为此目的使用不同的数据库。在这种情况下，优化几乎总是有效。

在某些情况下，应用程序使用相同的 XADatasource，JCA 只向 JTA 注册一个 XAResource，可能允许它使用更积极的 1PC 优化。

虽然连接确实可以在本地和 XA 事务上下文之间切换，但 JTA 目前无法利用这一点。由于资源仅按需征用，因此系统在到达终止阶段之前不知道有多少资源将参与交易。 JTA 规范组之前已经讨论过允许配置，类似于设置 tx 超时的方式，这将允许应用程序在开始时指示 tx 应该是单一资源，或者更一般地列出它应该包含的 XAResources。该信息将允许 JTA 在适当的情况下以本地 tx 模式而不是 XA 模式驱动资源，从而消除 start/end/prepare 协议调用。它还将消除通过为应用程序中的同一数据库部署 XA 和非 XA 数据源来手动优化此类情况的需要。不过它目前不在路线图上。

XA 数据源 1PC 优化

XA Datasource 1PC optimization

java

transactions

ejb

jta

xa