8.3. 事务锁定
8.3.1. pessimistic 事务缓存
从锁定的角度的角度来看，在写入密钥时，pessimistic 事务会获取密钥的锁定。
- 锁定请求发送到主所有者（可以是显式锁定请求或操作）
主所有者尝试获取锁定：
- 如果成功，它会发回正回复；
- 否则，会发送负回复，并回滚事务。
例如：
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 上的锁定会被释放。
注意
对于条件操作，验证在 originator 中执行。
8.3.2. 光率事务缓存
在事务准备时，会获取特定的事务锁定，且仅保留在事务提交（或回滚）上点。这与 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.
注意
对于条件命令，验证仍然在原始卷中发生。
8.3.3. 我需要什么 - pessimistic 或 optimistic 事务？
从用例的角度来看，当同时运行的多个事务之间没有竞争时，应使用选择的事务。这是因为，如果数据在读取和提交的时间之间有所变化（启用了 write skew 检查），则最佳事务回滚。
另一方面，当密钥和事务回滚有高竞争时，pessimistic 事务可能更加适合。Pessimistic 事务本身更经济：每个写入操作可能涉及 RPC 进行锁定。
