fencing token 还是解决不了 lost update 吧

[JasonLaw]

在How to do distributed locking — Martin Kleppmann’s blog中，Martin Kleppmann 说以下代码是 broken 的。

// THIS CODE IS BROKEN
function writeData(filename, data) {
    var lock = lockService.acquireLock(filename);
    if (!lock) {
        throw 'Failed to acquire lock';
    }

    try {
        var file = storage.readFile(filename);
        var updated = updateContents(file, data);
        storage.writeFile(filename, updated);
    } finally {
        lock.release();
    }
}

因为 Client 1 会覆盖掉 Client 2 所写的东西，如下图所示：

然后他说可以使用 fencing token 解决 lost update 问题，如下图所示，因为 Client 1 的 fencing token 小于 Storage 中的 token 。

但是如果 Client 1 先存进 Storage 呢？ Client 2 最后会覆盖掉 Client 1 所做的改变，这样不是还是存在 lost update 问题吗？因为 Client 2 所做的修改是基于旧的数据，在提交修改时，Client 2 的读已经过时了。

[2i2Re2PLMaDnghL]

我所知范围内，CouchDB 在写入时需要提供之前的 rev，类似 CAS 乐观锁。
应当是两个不同的机制，你提的这个问题我直觉上觉得更经典一些

[lance6716]

（没看原文链接），client2 如果是先读取这个值，运算后提交的话（比如 x=x+1 ）如果它从 storage 中读取到了 client1 的写入自然就是预期行为

[JasonLaw]

@lance6716 #2 啥意思？不太明白，能够具体描述一下吗？

[lance6716]

先存进 storage，然后 client1 解锁，client2 拿到锁，client2 读取到了 client1 的写入，没毛病

[lance6716]

哦哦，lost 是 client2 的 write lost 了

[JasonLaw]

@lance6716 #4 这种就是顺序执行了，肯定没啥问题，也就是“Client 1 获取到了锁，执行 read-modify-write，释放锁。接下来 Client 2 获取到了锁，执行 read-modify-write，释放锁”。

[JasonLaw]

@lance6716 #5 不是，我说的情况是 Client 2 最后会覆盖掉 Client 1 所做的改变，fencing token 也没用，因为 Client 2 的 token 就是比 Client 1 的大。

[Mikex88]

@JasonLaw lost update 发生在 write 和之前的 read 不一致。client2 read(拿锁) 的时候 client1 已经存进 Storage 啊

[JasonLaw]

@Mikex88 #8 你说“ client2 read(拿锁) 的时候 client1 已经存进 Storage 啊”，哪里看出来的？🤐

[Brentwans]

你说是有问题的，文章评论中有人提的。而且我个人觉得对于 token 这个算法就挺有问题的，都不需要边界场景。因为超期一旦当 client1 和 2 都申请到锁，大家都有所那就等于没有锁了呀。那如果这个 token 解决算法能弥补这个问题。是不是能够得出，我不要锁，直接用这个 token 算法就能解决安全问题了？

[Brentwans]

@Brentwans 打错了，你说的没错，的确是有这个问题的。