2014-09-19 62 views
0

比方说,我需要执行两种不同的写,可能同时出现数据存储上的实体操作,例如:优先化交易

  • 以便入场持有写锁定的客户端更新条目的内容
  • 的客户端请求写锁定的刷新(更新锁定的到期时间戳)

由于内容的更新操作如果客户持有当前写锁定只允许,我需要执行lock-c哎呀和内容写在一个交易(除非有另一种方式,我失踪?)。此外,锁定刷新必须在交易中发生,因为客户端需要首先被确认为当前锁定持有者。

锁定刷新是一个非常快速的操作。

内容更新操作可能非常复杂。把它看作是向服务器发送服务器在内容上执行的复杂更新脚本的客户端。

鉴于此,如果这两个事务之间存在冲突(应该同时执行),我宁愿让锁定刷新操作失败而不是复杂的内容更新。

有没有一种方法可以“优先处理”内容更新事务?我没有看到文档中的任何内容,我会想象这不是一个特定的功能,但也许有一些技巧我可以使用?

例如,如果我的content-update读取条目,将其写回并进行小修改(不提交事务),然后执行冗长的操作并最终写入结果并提交事务,会发生什么?第一次写入会立即应用并导致同时发生的锁定刷新事务失败?或者所有的写入都保存到最后交易被执行为止?

是否有这样的事情,保持两个交易打开?或者在交易中进行中间提交?

很明显,我可以将我的内容更新分成两个事务:第一个设置“不要混淆这个,请!” - 标志和第二个(稍后)写入更改并清除该标志。

但也许有一些其他的伎俩用较少的读/写/交易来实现这一点?

另一个想法我是,有数据的3个不同的“块”:当前锁保持器(LH),所述锁失效(EX),和正被修改的内容(CO)。锁定刷新操作需要在事务执行LH的读取和写入到EX,而内容的更新操作需要执行LH的读取,CO的读操作,和CO的事务中的写入。有没有办法将数据拆分为三个实体,并且以某种方式使事务仅跨越所需的实体?由于LH从未被这两个操作所修改,这可能有助于避免冲突的发生?

回答

1

数据存储使用乐观并发控制,这意味着(数据存储原语)交易等待,直到它被提交,然后成功只有当别人还没有将首先提交。通常,应用程序会重新尝试使用新数据的失败事务。没有办法修改这个第一赢的行为。

它可能有助于了解数据存储区事务处理的强大一致性,因此客户端可以首先使用同步数据存储区调用提交锁定刷新,并且当该调用返回时,客户端确切知道它是获取还是刷新锁定。客户端可以继续更新并锁定清除。你描述了锁定刷新和更新可能从同一个客户端同时发生的情况,这听起来是可以避免的。

我假设你需要锁定机制来防止在锁拥有者执行多个数据存储区基元事务时从其他客户端写入数据。如果客户端在释放锁之前实际上只进行一次更新,并且可以在几秒钟内(在数据存储区RPC超时之前)完成更新,那么您可能只通过具有乐观并发控制和重试的原始数据存储事务来处理。但是,对于用户界面中记录的简单序列化编辑,用户在用户界面中点击“编辑”按钮并且希望用户有足够的时间准备并提交更改而不会更改其他人的记录。 (无论这是你想要的用户体验是你的决定:))