假设我需要在可能同时发生的数据存储实体上执行两种不同类型的写操作，例如：
由于只有在客户端持有当前写锁的情况下才允许内容更新操作，我需要在事务中执行锁定检查和内容写入（除非我还缺少另一种方法吗？） 。此外，锁定刷新必须在事务中发生，因为客户端需要首先被确认为当前的锁定持有者。
锁定刷新是一种非常快速的操作。
内容更新操作可能非常复杂。可以把它想象成客户端向服务器发送服务器在内容上执行的复杂更新脚本。
鉴于此，如果这两个事务之间存在冲突（如果它们同时执行），我宁愿让锁定刷新操作失败而不是复杂的内容更新。
有没有办法可以“优先”内容更新交易？我没有在文档中看到任何内容，我会想到这不是一个特定的功能，但也许我可以使用一些技巧？
例如，如果我的内容更新读取条目，通过一个小的修改（不提交事务）将其写回，然后执行冗长的操作，最后写入结果并提交事务，会发生什么？第一次写入会立即应用并导致同时锁定刷新事务失败吗？或者所有写入都保留到最后提交事务？
是否存在保持两笔交易开放的事情？或者在事务中进行中间提交？
显然，我可以将内容更新分成两个事务：第一个设置“请不要弄乱这个，请！” - 标志，第二个（稍后）写入更改并清除该标志。
但也许还有其他一些技巧可以通过更少的读/写/事务来实现这一目标？
我的另一个想法是，有3个不同的“数据块”数据：当前锁定持有者（LH），锁定到期（EX）和正在修改的内容（CO）。锁定刷新操作需要在事务中执行LH的读取和对EX的写入，而内容更新操作需要在事务中执行LH的读取，CO的读取和CO的写入。有没有办法将数据分成三个实体，并以某种方式让事务只跨越所需的实体？由于LH永远不会被这两个操作修改，这可能有助于首先避免冲突吗？
答案 0 :(得分：1)
数据存储使用乐观并发控制，这意味着（数据存储原语）事务在提交之前等待，然后仅在其他人未提交时才成功。通常，应用程序使用新数据重试失败的事务。没有办法修改这个先赢的行为。
可能有助于了解数据存储区事务是非常一致的，因此客户端可以首先使用同步数据存储区调用提交锁定刷新，并且当该调用返回时，客户端确定它是否已获取或刷新锁定。然后，客户端可以继续进行更新并锁定。您描述的情况是，可以避免同一客户端同时发生锁定刷新和更新的情况。
我假设您需要锁机制来阻止来自其他客户端的写入，而锁所有者执行多个数据存储原语事务。如果客户端在释放锁之前实际上只进行了一次更新，并且它可以在几秒钟内（远在数据存储区RPC超时之前）完成，那么您可能只需要一个具有乐观并发控制和重试的原始数据存储区事务。但是，锁定对于简单的序列化（例如，对用户界面中的记录进行编辑）可能是一个好主意，用户界面中的用户点击编辑＆＃34;用户界面中的按钮，您希望这可以保证用户有一些时间准备和提交更改，而不会由其他人更改记录。 （这是否是您想要的用户体验是您的决定。:)）