我正在使用 rowversion 对一组数据进行乐观并发：客户端获取一批数据，进行一些更新，然后将更新发送到数据库。管理乐观并发的最简单解决方案似乎是此处描述的解决方案：在检索时，只需从感兴趣的数据中获取单个最大的 rowversion（或者甚至只是数据库的最后使用的 rowversion 值），并将其发送给客户端。当请求更新时，让客户端发回该值，然后确保更新中涉及的所有行的 rowversion 值小于或等于客户端发送的值。更新时，数据库中任何行版本高于发送到客户端的行必须在初始检索后更新，并且应提示用户刷新并重试，或者任何所需的体验。
这对我来说似乎很明显的问题是，客户端很容易简单地发回 UInt64.MaxValue 或其他一些大值并完全解决这个问题。
经过一番搜索，我看到了很多解决方案的描述，这些解决方案涉及向客户端发送行版本以管理乐观并发，但没有提到这种问题。
用于乐观并发检查的数据值是否应该由服务器签名和验证，或者是否应该将服务器端存储在用户会话缓存或类似的东西中，而不是实际发送给用户？或者应用程序的设计是否应该考虑乐观并发检查只是良好用户体验的一部分而不是安全功能 - 即并发检查应该只存在于帮助确保用户（他们应该被适当授权首先接触这些数据无论如何放置）正在根据新数据做出决策，即使有人竭尽全力破坏并发检查，应用程序也应该正常运行？
我倾向于后者，但它让我停下来思考使用不安全的、客户端提供的 rowversion 值的应用程序，并且只是盲目地将用户更新放入数据库而不对正在更新的行执行任何类型的健全性检查......