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.
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.