Concurrence DB - Checksum vs Timestamp

Question

Nous sommes en train de passer à un nouveau système de base de données. La base de données est de type ISAM et l'API ne permet pas de détecter si un enregistrement a été modifié par un autre utilisateur.

Par conséquent, j'ai besoin d'implémenter cette fonctionnalité du côté client. Je calcule actuellement une somme de contrôle en utilisant les tampons d'enregistrement avant et après et en comparant le résultat.

Ma question est, puisqu'il y a une chance que la même valeur de somme de contrôle puisse être calculée pour deux enregistrements différents, serait-il préférable d'avoir un champ timestamp à la place?

Comment la détection de changement d'enregistrement est-elle normalement gérée?

Merci.

Answer 1

Mieux ne serait pas un horodatage, ce qui n'est pas fiable, mais un champ entier version, que votre code client peut utiliser pour détecter les modifications simultanées dans la base de données.

Ceci est appelé "verrouillage optimiste", lorsque votre transaction ne verrouille aucune ressource de base de données, jusqu'au moment de mettre à jour la base de données. À ce moment, il verrouille les ressources de base de données nécessaires (par exemple, les tables), lit la version de la base de données et vérifie si sa valeur est attendue. Si oui, cela signifie qu'il est sûr de mettre à jour la base de données avec le numéro de version dans la base de données. Si non, cela signifie que la mise à jour et la transaction simultanées doivent être annulées.

Bien sûr, si vous aviez beaucoup d'abandons, cela signifie que vous auriez besoin de "verrouillage pessimiste", où votre application verrouille toutes les ressources pour l'ensemble de la transaction. Si votre pilote de base de données ne le supporte pas, vous aurez besoin d'un autre verrou partagé, comme un mutex. Cette approche réduit le débit dans la plupart des cas, car les transactions simultanées doivent attendre qu'une transaction libère des ressources verrouillées.