我在一组数据上使用rowversion进行乐观并发：客户端获取一批数据，进行一些更新，然后将更新发送到数据库。用于管理乐观并发的最简单的解决方案似乎是here所描述的：在检索时，只从感兴趣的数据中获取单个最大的rowversion（或者甚至只是数据库最后使用的rowversion值），并将其发送到客户端。请求更新时，让客户端返回值，然后确保更新中涉及的所有行的rowversion值小于或等于客户端发送的值。在更新时，数据库中具有比发送到客户端的行更高的行的任何行必须在初始检索后更新，并且应提示用户刷新并再次尝试，或者无论期望的体验是什么。
在我看来这个问题显而易见的问题是，客户端很容易发送回UInt64.MaxValue或其他一些大值并完全失败。
经过一番搜索后，我看到了很多关于解决方案的描述，这些解决方案涉及向客户端发送rowversions以管理乐观并发，但没有提到这种关注。
用于乐观并发检查的数据值是应该由服务器签名和验证，还是存储在服务器端的用户会话缓存或类似的东西而不是实际发送给用户？或者，应用程序的设计是否应该将乐观并发检查视为良好用户体验的一部分而不是安全功能 - 即应该只存在并发检查以帮助确保用户（应该在第一时间正确授权用户触摸此数据）无论如何）正在根据新数据做出决定，即使有人不顾一切地打败并发检查，应用程序也能正常运行？
我倾向于后者，但它让我停下来思考使用不安全的，客户端提供的rowversion值的应用程序，只是盲目地将用户更新丢入数据库而不对正在更新的行执行任何形式的健全性检查...