数据库并发 - 校验和与时间戳
我们正在迁移到新的数据库系统。数据库是 ISAM 类型，并且 API 不提供检测记录是否已被其他用户更改的方法。
因此我需要在客户端实现这个功能。我目前正在使用之前和之后的记录缓冲区计算校验和并比较结果。
我的问题是，由于有可能为两个不同的记录计算相同的校验和值，因此使用时间戳字段会更好吗？
通常如何处理记录更改检测？
谢谢。
we are in the process of moving to a new database system. The database is of ISAM type and the API does not provide a way to detect if a record has been changed by another user.
Therefore I need to implement this functionality on the client side. I am currently calculating a checksum using the before and after record buffers and comparing the result.
My question is, since there is a chance that the same checksum value can be calculated for two different records, would it be better to have a timestamp field instead?
How is record changed detection normally handled?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
更好的是不是不可靠的时间戳，而是整数字段版本，您的客户端代码可以使用它来检测数据库中的并发更改。
这称为“乐观锁定”，即您的事务不会锁定任何数据库资源，直到更新数据库为止。此时它锁定所需的数据库资源（例如表），从数据库读取版本并检查它是否具有预期值。如果是，这意味着更新数据库以及数据库中的版本号是安全的。如果不是，则意味着存在并发更新并且事务需要中止。
当然，如果您有很多中止，则意味着您需要“悲观锁定”，即您的应用程序锁定整个事务的所有资源。如果您的数据库驱动程序不支持这一点，您将需要一些其他共享锁，例如互斥锁。在大多数情况下，这种方法会降低吞吐量，因为并发事务必须等待一个事务释放锁定的资源。
Better would be not a timestamp, which is unreliable, but an integer field version, which your client code may use to detect concurrent changes in DB.
This is called "optimistic locking", when your transaction doesn't lock any DB resources, until it's time to update DB. At this moment it locks needed DB resources (e.g., tables), reads version from DB and checks if it's has expected value. If yes, this means it's safe to update database along with version number in DB. If no, this means there was concurrent update and transaction needs to abort.
Of course, if you would have lot of aborts, it means you would need "Pessimistic locking", where your app locks any resources for the whole transaction. If your DB driver not support this, you'll need some other shared lock, like a mutex. This approach decreases throughput in most cases, since concurrent transactions must wait until one transaction frees locked resources.