第 9 章 配置事务

从锁定的角度来看，模糊的事务会在写入密钥时获得密钥锁定。

例如：

transactionManager.begin();
cache.put(k1,v1); //k1 is locked.
cache.remove(k2); //k2 is locked when this returns
transactionManager.commit();

当 cache.put (k1,v1) 返回时，k1 被锁定，并且集群中任何其它事务都可以写入它。仍可读取 k1。当事务完成时（提交或回滚）时，k1 上的锁定会被释放。

使用最佳事务锁定会在交易准备时获取，且仅保留事务提交（或回滚）的点。这与 5.0 默认锁定模型不同，其中本地锁定在进行写入时获得，在准备过程中会获取集群锁定。

例如：

transactionManager.begin();
cache.put(k1,v1);
cache.remove(k2);
transactionManager.commit(); //at prepare time, K1 and K2 is locked until committed/rolled back.

从用例的角度来看，当同时运行多个事务之间没有许多竞争时，应使用最佳事务。这是因为，如果在读取数据和提交时间（启用了写偏移检查）之间更改了数据，则最佳事务回滚。

另一方面，当密钥和事务回滚中发生大量竞争时，模糊的事务可能会更加适合。Pessimistic 事务的性质更加昂贵：每个写入操作都可能涉及对锁定的 RPC。

为了避免写入带有 pessimistic 事务的 skews，使用 Flag.FORCE_WRITE_LOCK 在读取时锁定密钥。

将以下代码片段与 Flag.FORCE_WRITE_LOCK 示例进行比较：

// begin the transaction
if (!cache.getAdvancedCache().lock(key)) {
   // abort the transaction because the key was not locked
} else {
   cache.get(key);
   cache.put(key, value);
   // commit the transaction
}

// begin the transaction
try {
   // throws an exception if the key is not locked.
   cache.getAdvancedCache().withFlags(Flag.FORCE_WRITE_LOCK).get(key);
   cache.put(key, value);
} catch (CacheException e) {
   // mark the transaction rollback-only
}
// commit or rollback the transaction

将缓存配置为使用批处理后，您可以通过在 Cache 上调用 startBatch （） 和 endBatch （） 来使用它。例如，

Cache cache = cacheManager.getCache();
// not using a batch
cache.put("key", "value"); // will replicate immediately

// using a batch
cache.startBatch();
cache.put("k1", "value");
cache.put("k2", "value");
cache.put("k2", "value");
cache.endBatch(true); // This will now replicate the modifications since the batch was started.

// a new batch
cache.startBatch();
cache.put("k1", "value");
cache.put("k2", "value");
cache.put("k3", "value");
cache.endBatch(false); // This will "discard" changes made in the batch

在后台，批处理功能会启动 JTA 事务，该范围中的所有调用与其相关联。为此，它使用非常简单（如无恢复）内部 TransactionManager 实现。通过批处理，您将获得：

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

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

现在，系统管理员能够连接到 Data Grid 集群，并重新执行事务提交或强制回滚。Data Grid 为此提供了 JMX 工具，这在 Transaction recovery and reconciliation 部分中进行了广泛解释。

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

注意： restore-cache 属性不是强制的，它是按缓存配置的。

为了跟踪不疑的事务并能够回复它们，Data Grid 会缓存所有事务状态，以备将来使用。这个状态只适用于 in-doubt 事务，在提交/滚动阶段完成后为成功完成事务删除。

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

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

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

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

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

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

正常恢复流是：

图 9.1. 显示 in-doubt 事务

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

图 9.2. 强制提交