Trois problèmes soulevés par la concurrence.
Introduction
Nous proposons ci-dessous trois problèmes posés par les accès concurrents des transactions aux données.
Perte de mise à jour
Les transaction A et B accèdent au même tuple T ayant la même valeur respectivement à t1 et t2. Ils modifient chacun la valeur de T. Les modifications effectuées par A seront perdues puisqu'elle avait lu T avant sa modification par B.
Exemple :
Dans cet exemple le compte bancaire vaut 1010 à la fin des deux transactions à la place de 1110.
Accès à des données non validées
La transaction A accède au tuple T qui a été modifié par la transaction B. B annule sa modification et A a donc accédé à une valeur qui n'aurait jamais dû exister (virtuelle) de T. Pire A pourrait faire une mise à jour de T après l'annulation par B, cette mise à jour inclurait la valeur avant annulation par B (et donc reviendrait à annuler l'annulation de B).
Exemple :
Dans cet exemple le compte bancaire vaut 1110 à la fin des deux transactions à la place de 1010.
Lecture incohérente
Si au cours d'une même transaction A accède deux fois à la valeur d'un tuple alors que ce dernier est, entre les deux, modifié par une autre transaction B, alors la lecture de A est inconsistente. Ceci peut entraîner des incohérences par exemple si un calcul est en train d'être fait sur des valeurs par ailleurs en train d'être mises à jour par d'autres transactions.
Remarque :
Le problème se pose bien que la transaction B ait été validée, il ne s'agit donc pas du problème d'accès à des données non validées.
Exemple :
Dans cet exemple la somme calculée vaut 210 à la fin du calcul alors qu'elle devrait valoir 200.