10.8. 事务恢复

考虑一个分布式交易，其中资金从存储在外部数据库中的帐户转移到 Data Grid 中存储的帐户。当调用 TransactionManager.commit （） 时，两个资源都会成功准备(1st 阶段)。在提交(2nd)阶段，数据库在从事务管理器接收提交请求前成功应用更改 whilst Data Grid 失败。此时系统处于不一致的状态：从外部数据库中的帐户获得资金，但还没有在 Data Grid （因为锁定仅在双阶段提交协议的 2nd 阶段发布）。恢复处理这种情况，以确保数据库和数据网格都处于一致状态。

恢复由事务管理器协调。事务管理器与 Data Grid 合作，以确定需要人工干预并告知系统管理员（通过电子邮件、日志警报等）的异常事务列表。这个过程是特定于事务管理器的，但通常需要在事务管理器中进行一些配置。  

知道 in-doubt 事务 ID，系统管理员现在可以连接到 Data Grid 集群，并重播事务提交或强制回滚。Data Grid 提供 JMX 工具 - 这在 Transaction recovery and reconciliation 部分中进行了广泛阐述。

Data Grid 中不默认启用恢复。如果禁用，TransactionManager 将无法与 Data Grid 一起使用，以确定 in-doubt 事务。Transaction configuration 部分演示了如何启用它。

注意： recovery-cache 属性不是强制的，它被配置为每个缓存。

为了跟踪新的交易并能够回复它们，数据网格会缓存所有事务，供未来使用。这个状态仅为 in-doubt 事务保存，在提交/滚动阶段完成后，会删除成功完成事务。

这种不疑的交易数据保存在本地缓存中：这样，在它太大时，可以通过缓存加载程序将这些信息交换到磁盘。此缓存可以通过 recovery-cache 配置属性指定。如果没有指定 Data Grid，则会为您配置本地缓存。

（尽管强制）可以在启用了恢复的所有 Data Grid 缓存之间共享相同的恢复缓存。如果覆盖默认恢复缓存，则指定的恢复缓存必须使用 TransactionManagerLookup，它返回一个与缓存本身所使用的不同的事务管理器。

虽然这是特定于事务管理器的，但通常需要一个事务管理器对 XAResource 实现的引用，才能在其上调用 XAResource.recover （）。要获得对 Data Grid XAResource 的引用，可以使用以下 API：

XAResource xar = cache.getAdvancedCache().getXAResource();

常见做法是在与运行事务的不同进程中运行恢复。

事务管理器将以专有方式通知系统管理员不疑事务。在此阶段，系统管理员知道事务的 XID （字节阵列）。

普通的恢复流程是：

图 10.1. show in-doubt 事务

此时会显示每个 in-doubt 事务的状态（在本示例中" PREPARED "）。status 字段中可能存在多个元素，例如：在某些节点上提交但不是所有节点上的事务时，"PREPARED"和"COMMITTED"。  

图 10.2. 强制提交

恢复设计文档 更详细地描述了事务恢复实现内部。