使用 WebSphere 中间件构建高可用性数据库环境，第 3 部分

核心提示： 下面是一个描述此问题的假定情形，假设有一个两节点的 Oracle 10G RAC 环境（带有节点 rac-node1 和 rac-node2），使用 WebSphere 中间件构建高可用性数据库环境，第 3 部分(5)，在此环境中，同时启用了故障转移和负载平衡：应用程序在 WebSphere A

下面是一个描述此问题的假定情形。假设有一个两节点的 Oracle 10G RAC 环境（带有节点 rac-node1 和 rac-node2），在此环境中，同时启用了故障转移和负载平衡：

应用程序在 WebSphere Application Server 集群成员中启动了一个用户事务（称为 UTx）。

在 UTx 边界内，该应用程序请求一个数据库连接。假定该连接是从 rac-node1 提供的。

该应用程序向同一 Oracle 数据库资源管理器请求另一连接，该连接通过 rac-node2 提供，这是另一个 RAC 节点。

这会在两个连接上同时执行工作，从而导致启动两个事务分支：TxB1 和 TxB2。

假设在 WebSphere Application Server 事务管理器发出对 TxB1 的 xa.prepare() 调用之后并调用 xa.commit() 之前，RAC 节点 (rac-node1) 出现故障。

这时，WebSphere 事务管理器将收到 XAER_RMFAIL 返回代码，该代码指示资源管理器不可用。

WebSphere 事务管理器将尝试获取到 RAC 的新连接。由于支持故障转移，所以在 RAC 端完成恢复后（即已为业务打开 Oracle RAC），Oracle JDBC 驱动程序将从 rac-node2 提供连接。

WebSphere 事务管理器将通过发出 xa.commit() 尝试完成 TxB1。

Oracle JDBC 驱动程序可能会抛出 ORA-24756：事务不存在这一异常；仍然运行的 RAC 节点 rac-node2 甚至还不知道事务分支 TxB1。

TxB1 将处于一种未决状态，这时，如果 TxB1 正好持有某些数据库锁，则可能会导致问题。

任何对被 TxB1 分支锁定的同一数据库行或表的后续访问尝试都将导致“ORA-01591 lock held by in-doubt distributed transaction”（ORA-01591 锁由未决的分布式事务持有）异常，从而导致数据库的某些部分不可用。