Les accès concurrents

Quelle vision des données?

Effets des accès concurrents sur la lecture de données :

• lecture sale : une transaction lit des données écrites par une transaction concurrente non validée;
• lecture non reproductible : une transaction relit des données et obtient des données modifiées (à cause d'une transaction concurrente validée);
• lecture d'enregistrements fantômes : une transaction re-exécute une requête et obtient un ensemble d'enregistrements différents (à cause d'une transaction concurrente validée)

Le standard SQL définit 4 niveaux d'isolation des transactions.

Niveau d'isolation	lect. sale	lec. non repr.	lect. fant.
read uncommited	possible	possible	possible
read commited	impossible	possible	possible
repeatable read	impossible	impossible	possible
serializable	impossible	impossible	impossible

PostgreSQL fournit les niveaux read commited et serializable.

Chaque session concurrente voit un cliché de la base. Le résultat des requêtes dépend donc du moment où est pris le cliché.

• read commited :
  • cliché pris en début de chaque requête, sur des modifications validées
  • cas d'une requête R UPDATE ou DELETE : si une transaction B concurrente accède en modification les mêmes enregistrements alors R bloquée jusqu'à validation ou annulation de B
  • conditions de recherche sont ré-évaluées pour les enregistrements satisfaisant R : R effectuée pour ceux satisfaisant toujours les critères

Exemple avec deux UPDATE concurrents.

temps | session A                  | session B
t     | ex=# begin;                | ex=# begin;         
      | BEGIN                      | BEGIN
t+1   | ex=# update voiture        | 
      |      set couleur='rose'    |                  
      |      where id_voiture=1;   |                      
t+2   | UPDATE 1                   |                      
t+3   |                            | ex=# update voiture
      |                            |      set nom = 'truc'
      |                            |      where id_voiture=1;

...   |                            | -- requête bloquée!!

t+10  | ex=# commit;               |    
t+11  | COMMIT                     | UPDATE 1
t+12  |                            | ex=# commit;
t+13  |                            | COMMIT

Exemple avec un INSERT et un UPDATE concurrents.

temps | session A                  | session B
t     | ex=# begin;                | ex=# begin;         
      | BEGIN                      | BEGIN
t+1   |                            | ex#= select count(id_voiture)
      |                            |      from voiture
t+2   | ex=# insert into voiture   |      where couleur = 'rose';
      |      (couleur)             |  count               
      |      values('rose');       | ------
      | INSERT 1                   |  3
t+3   |                            | ex=# update voiture
      |                            |      set couleur = 'mauve'
      |                            |      where couleur = 'rose'
t+4   | ex=# commit;               | UPDATE 3
t+5   | COMMIT                     | 
t+6   |                            | ex=# commit;
t+7   |                            | COMMIT

Exemple avec un UPDATE et un DELETE concurrents.

temps | session A                  | session B
t     | ex=# begin;                | ex=# begin;         
      | BEGIN                      | BEGIN
t+1   | ex=# select couleur from   | ex#= select count(id_voiture)
      |      voiture where         |      from voiture
      |      id_voiture = 3;       |      where couleur = 'rose';
t+2   |  couleur                   |  count     
      | --------                   | ------                
      |  rose                      | 3
t+3   | ex=# delete from voiture   | 
t+4   |      where id_voiture=3;   | ex=# update voiture
      | DELETE 1                   |      set couleur = 'mauve'
      |                            |      where couleur = 'rose'
t+5   | ex=# commit;               |   -- requête bloquée!!
t+6   | COMMIT                     | UPDATE 2
t+7   |                            | ex=# commit;
t+8   |                            | COMMIT

Attention : au niveau d'isolation read committed, comme deux SELECT qui se suivent ne voient pas la même version de la base, cela peut donner des incohérences au niveau de la transaction.

• Serializable : le niveau le plus strict d'isolation.
  • cliché de la base pris au début de la première requête de la transaction
  • conservé pour toute la durée de la transaction
  • ordre UPDATE ou DELETE : si modification des enregistrements par une transaction concurrente, la transaction échoue
  • $\Longrightarrow$ nécessité de retenter des transactions échouées
  • transactions qui n'effectuent que des lectures n'ont jamais de conflits, et proposent une vue complètement cohérente sur toute la transaction.