Problèmes d'isolation?
Il y a peu, j'ai écrit sur les différents niveaux d'isolation disponibles sur les bases de données et le fait que finalement on reste souvent sur le niveau par défaut malgré les risques occasionnés (https://dantheengineer.com/cest-quoi-une-transaction-acid/).
Comme on peut s'en douter, une isolation entre les transactions imparfaite peut provoquer des risques sur la cohérence des données tout comme sur la logique métier que l'on souhaite gérer.
Dans ce nouvel article, je vais donner 2 exemples concrets de problèmes issus d'un niveau d'isolation plus faible que Serialisable.
Phantom Read
Les phantom read sont des lectures qui ne donnent pas le même résultat entre plusieurs lectures au sein d'une même transaction.
Si nous imaginons un système de facturation fin de mois qui fonctionne comme ceci:
- Affichage du montant à facturer
- Démarrage de la facturation
Si une transaction modifie la liste de comptes entre l'étape 1 et 2, le montant facturé sera différent de celui calculé en amont. Cette transaction pourrait être générée par un autre système gérant la liste de clients devant faire l'objet d'une facturation sur la période.
Cette anomalie d'isolation peut engendre un souci métier relativement complexe à résoudre afin de comprendre pourquoi la facturation n'est pas complète. Le système de facturation n'aura commis aucune erreur, la modification de l'état des clients n'a pas non plus d'erreur dans les logs.
Write Skew
Imaginons un système responsable de la disponibilité des médecins durant une garde. Chaque médecin va pouvoir voir les disponibilités et demander une absence si il reste au moins un autre médecin.
Mais que se passe-t-il si les 2 médecins de garde ouvre leur poste, constate qu'ils peuvent poser leur jour et le valide chacun sur un poste de travail au même moment?
C'est ce qu'on appelle un Write Skew. Les données issues d'un SELECT qui sont impactées par une autre transaction devraient bloquer notre transaction. Mais ce n'est pas le cas si notre transaction n'est pas serialisable.
Dans notre exemple, il n'y aura aucun médecin de garde le jour j.
Avec un exemple c'est mieux
Pour illustrer ces notions, j'ai publié le repository suivant:
HytmL'outil utilise 2 arguments
- write: pour montrer un write skew
- phantom: pour démontrer un souci de phantom read
Il faudra aussi configurer votre fichier .env en prenant exemple sur le fichier .env-example, afin de configurer la connexion vers PostgreSQL et CockroachDB.
Pour CockroachDB, si vous n'en avez pas, vous pouvez simplement et rapidement créer votre cluster Serverless.