8.8. 事务恢复

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

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

了解 in-doubt transaction ids，系统管理员现在可以连接到 Data Grid 集群，并重播事务的提交或强制回滚。Data Grid 提供了 JMX 工具 - 这在 交易恢复和协调 部分中进行了广泛说明。

在 Data Grid 中不默认启用恢复。如果禁用，TransactionManager 将无法与 Data Grid 合作来确定 in-doubt 事务。事务配置 部分演示了如何启用它。

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

为了跟踪 in-doubt 事务并能够回复它们，Data Grid 会缓存所有事务状态以供将来使用。此状态仅针对 in-doubt 事务而保留，在提交/注册阶段完成后为成功完成的事务被删除。

这个 in-doubt 事务数据保存在本地缓存中：这允许一个通过缓存加载程序将这个信息转换为磁盘，以防它太大。此缓存可以通过 recovery-cache 配置属性来指定。如果没有指定 Data Grid，则会为您配置本地缓存。

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

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

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

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

事务管理器以专有的方式告知系统管理员在不做的事务中。在这个阶段，系统管理员知道事务的 XID （字节阵列）。

正常恢复流程是：

图 8.1. 显示 in-doubt 事务

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

图 8.2. 强制提交