这是一个经典的并发读写挑战：
我们正在通过 Hibernate 向 Oracle 数据库发布记录和 Atom Hopper 供稿，我们的合作伙伴正在阅读它们。如果我们发布记录 1 到 5，那么 5 是头部（即最后发布的）。我们的合作伙伴要求从条目 1 开始的提要页面，并接收条目 1-5。下次他们询问时，他们将要求比条目 5 更新的条目。客户端跟踪已读取的条目。
问题是，当他们阅读时，我们碰巧发布了一个条目号 6，它在“已创建”列中的时间戳比数字 5 稍早。因为它是在读取后提交的，所以我们的合作伙伴永远不会得到 nr。6. 他们得到了我们在此期间发布的 7、8 和 9，所有这些都具有比 nr 更新的时间戳。5.
那么如何避免丢失像nr这样的条目。6？我们让数据库将时间戳设置为第一个度量，但是我们仍然有可能在它们读取时提交“较旧”条目，因为在记录获取时间戳和提交时间戳之间存在不可忽略的时间. 是否可以锁定数据库页面以供阅读之类的？
我想我们可能不得不改变客户行为，即要求比 4 号更新的条目，以防两者之间有提交。在捕获诸如 nr 之类的提交方面，使用序列而不是时间戳会更好。6？