Niveau d’isolation : READ COMMITTED

Y a comme un défaut...

      Les systèmes de gestion de bases de données relationnelles sont connus pour leurs propriétés ACID. Le I signifie ISOLATION. De multiples transactions peuvent être gérées simultanément par un SGBDR. Le standard SQL définit plusieurs niveaux d’isolation fixant les règles régissant la concurrence entre ces transactions. Dans cet article nous allons nous intéresser au niveau utilisé par défaut par PostgreSQL et Oracle, le READ COMMITTED. Ce niveau n’autorise pas les lectures sales (dirty reads) présentées dans l’article sur le niveau READ UNCOMMITTED mais autorise les lectures non reproductibles (nonrepeatable read). Cela signifie qu’en essayant de relire les mêmes données dans une transaction vous pouvez constater qu’elles ont changé. En effet, d’autres transactions peuvent avoir manipulé ces données en les mettant à jour ou en les supprimant et peuvent avoir validé ces changements.
      Démonstration avec PostgreSQL 9.6 :

select version(); version ------------------------------------------------------------------------------------------ PostgreSQL 9.6.1 on x86_64-pc-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit (1 ligne) - session 0 CREATE TABLE t1(c1 SMALLINT); CREATE TABLE INSERT INTO t1(c1) VALUES(1); INSERT 0 1 COMMIT; COMMIT UPDATE t1 SET c1 = 2; UPDATE 1 -- session 1 START TRANSACTION; START TRANSACTION SET TRANSACTION ISOLATION LEVEL READ COMMITTED; SET SELECT * FROM t1; c1 ---- 1 (1 ligne) -- session 2 START TRANSACTION; START TRANSACTION SELECT * FROM t1; c1 ---- 1 (1 ligne) -- session 0 COMMIT; COMMIT -- suite session 1 SELECT * FROM t1; c1 ---- 2 (1 ligne) -- suite session 2 SELECT * FROM t1; c1 ---- 2 (1 ligne)

      PostgreSQL se comporte comme le standard SQL le prévoit. Nous n’avons pas obtenu de lecture sale mais avons obtenu une lecture non reproductible dans la transaction de la session 1 (niveau d’isolation READ COMMITTED affecté explicitement) comme dans la transaction de la session 2 (niveau d’isolation READ COMMITTED affecté par défaut). En effet, lors du deuxième "SELECT * FROM t1", nous avons relu l’unique ligne de la table t1 et nous avons obtenu un résultat différent de celui obtenu lors du premier "SELECT * FROM t1".
      A présent un test avec Oracle Database dans sa version 11.2.0.2 :

Connected to: Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production -- session 0 SQL> CREATE TABLE t1(c1 SMALLINT); Table created. SQL> INSERT INTO t1 VALUES(1); 1 row created. SQL> COMMIT; Commit complete. SQL> UPDATE t1 SET c1 = 2; 1 row updated. -- session 1 SQL> SET TRANSACTION ISOLATION LEVEL READ COMMITTED; Transaction set. SQL> SELECT * FROM t1; C1 ---------- 1 -- session 2 SQL> SELECT * FROM t1; C1 ---------- 1 -- session 0 SQL> COMMIT; Commit complete. -- session 1 suite SQL> SELECT * FROM t1; C1 ---------- 2 -- session 2 suite SQL> SELECT * FROM t1; C1 ---------- 2

      Oracle Database se comporte comme PostgreSQL en ce qui concerne le niveau d’isolation READ COMMITTED et il s’agit également de son niveau d’isolation par défaut.

Mise à jour : 09/11/2016