Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Niveaux d’isolement des transactions dans Babelfish
<a name="babelfish-transaction"></a>

Babelfish prend en charge les niveaux d’isolement des transactions `READ UNCOMMITTED`, `READ COMMITTED` et `SNAPSHOT`. À partir de la version 3.4 de Babelfish, les niveaux d’isolement supplémentaires `REPEATABLE READ` et `SERIALIZABLE` sont pris en charge. Tous les niveaux d’isolement de Babelfish sont pris en charge avec le comportement des niveaux d’isolement correspondants dans PostgreSQL. SQL Server et Babelfish utilisent différents mécanismes sous-jacents pour implémenter les niveaux d’isolement des transactions (blocage des accès simultanés, verrous détenus par les transactions, gestion des erreurs, etc.). Il existe aussi des différences subtiles dans la manière dont l’accès simultané peut fonctionner pour différentes charges de travail. Pour plus d’informations sur ce comportement de PostgreSQL, consultez [Isolement des transactions](https://www.postgresql.org/docs/current/transaction-iso.html). 

**Topics**
+ [Présentation des niveaux d’isolement des transactions](#babelfish-transaction.overview)
+ [Configuration des niveaux d’isolement des transactions](#babelfish-transaction.setting)
+ [Activation ou désactivation des niveaux d’isolement des transactions](#babelfish-transaction.enabling)
+ [Comparaison des niveaux d’isolement Babelfish et SQL Server](babelfish-transaction.examples.md)

## Présentation des niveaux d’isolement des transactions
<a name="babelfish-transaction.overview"></a>

 Les niveaux d’isolement des transactions SQL Server d’origine sont basés sur un verrouillage pessimiste où il n’existe qu’une seule copie des données et où les requêtes doivent verrouiller des ressources telles que les lignes avant de pouvoir y accéder. Par la suite, une variation du niveau d’isolement `READ COMMITTED` a été introduite. Cela permet d’utiliser des versions de ligne pour améliorer la simultanéité entre les lecteurs et les rédacteurs en utilisant un accès non bloquant. De plus, un nouveau niveau d’isolement appelé `SNAPSHOT` est disponible. Il utilise également des versions de ligne pour offrir une meilleure simultanéité que le niveau d’isolement `REPEATABLE READ` en évitant le verrouillage partagé des données de lecture qui sont bloquées jusqu’à la fin de la transaction.

Contrairement à SQL Server, tous les niveaux d’isolement des transactions de Babelfish sont basés sur le verrouillage optimiste (MVCC). Chaque transaction affiche un instantané des données au début de l’instruction (`READ COMMITTED`) ou au début de la transaction (`REPEATABLE READ`, `SERIALIZABLE`), quel que soit l’état actuel des données sous-jacentes. Par conséquent, le comportement d’exécution des transactions simultanées dans Babelfish peut être différent de celui de SQL Server.

Prenons l’exemple d’une transaction avec un niveau d’isolement `SERIALIZABLE` initialement bloqué dans SQL Server, mais qui aboutit ultérieurement. Elle peut échouer dans Babelfish en raison d’un conflit de sérialisation avec une transaction simultanée qui lit ou met à jour les mêmes lignes. Il peut également arriver que l’exécution de plusieurs transactions simultanées produise un résultat final différent dans Babelfish par rapport à SQL Server. Les scénarios de simultanéité des applications qui utilisent des niveaux d’isolement doivent être testés minutieusement. 


| Niveaux d’isolement dans SQL Server | Niveau d’isolement Babelfish | Niveaux d’isolement PostgreSQL | Commentaires | 
| --- | --- | --- | --- | 
|  `READ UNCOMMITTED`  |  `READ UNCOMMITTED`  |  `READ UNCOMMITTED`  |  `READ UNCOMMITTED` est le même que `READ COMMITTED` dans Babelfish ou PostgreSQL  | 
|  `READ COMMITTED`  |  `READ COMMITTED`  |  `READ COMMITTED`  |  `READ COMMITTED` dans SQL Server est basé sur le verrouillage pessimiste, `READ COMMITTED` dans Babelfish est basé sur les instantanés (MVCC).  | 
|  `READ COMMITTED SNAPSHOT`  |  `READ COMMITTED`  |  `READ COMMITTED`  |  Les deux sont basés sur des instantanés (MVCC), mais ne sont pas exactement les mêmes.  | 
|  `SNAPSHOT`  |  `SNAPSHOT`  |  `REPEATABLE READ`  |  Exactement pareil.  | 
|  `REPEATABLE READ`  |  `REPEATABLE READ`  |  `REPEATABLE READ`  |  `REPEATABLE READ` dans SQL Server est basé sur le verrouillage pessimiste, `REPEATABLE READ` dans Babelfish est basé sur les instantanés (MVCC).  | 
|  `SERIALIZABLE`  |  `SERIALIZABLE`  |  `SERIALIZABLE`  |  `SERIALIZABLE` dans SQL Server est un système d’isolement pessimiste, `SERIALIZABLE` dans Babelfish est basé sur les instantanés (MVCC).  | 

**Note**  
Les indicateurs de table ne sont actuellement pas pris en charge, et leur comportement est contrôlé à l’aide de la trappe de secours prédéfinie `escape_hatch_table_hints` de Babelfish.

## Configuration des niveaux d’isolement des transactions
<a name="babelfish-transaction.setting"></a>

Utilisez la commande suivante pour définir le niveau d’isolement des transactions :

**Example**  

```
SET TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SNAPSHOT | SERIALIZABLE }
```

## Activation ou désactivation des niveaux d’isolement des transactions
<a name="babelfish-transaction.enabling"></a>

Les niveaux d’isolement des transactions `REPEATABLE READ` et `SERIALIZABLE` sont désactivés par défaut dans Babelfish. Vous devez donc les activer explicitement en réglant l’utilisation de la trappe de secours `babelfishpg_tsql.isolation_level_serializable` ou `babelfishpg_tsql.isolation_level_repeatable_read` sur `pg_isolation` à l’aide de `sp_babelfish_configure`. Pour plus d’informations, consultez [Gestion du traitement des erreurs Babelfish avec des trappes de secours](babelfish-strict.md).

Vous trouverez ci-dessous des exemples d’activation ou de désactivation de l’utilisation de `REPEATABLE READ` et `SERIALIZABLE` dans la session en cours en définissant leur trappe de secours respective. Incluez éventuellement un paramètre `server` pour définir la trappe de secours pour la session en cours ainsi que pour toutes les nouvelles sessions suivantes.

 Pour activer l’utilisation de `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ` uniquement dans la session en cours. 

**Example**  

```
EXECUTE sp_babelfish_configure 'isolation_level_repeatable_read', 'pg_isolation'
```

 Pour permettre l’utilisation de `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ` dans la session en cours et dans toutes les nouvelles sessions qui en découlent. 

**Example**  

```
EXECUTE sp_babelfish_configure 'isolation_level_repeatable_read', 'pg_isolation', 'server'
```

 Pour désactiver l’utilisation de `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ` dans la session en cours et dans les nouvelles sessions qui en découlent. 

**Example**  

```
EXECUTE sp_babelfish_configure 'isolation_level_repeatable_read', 'off', 'server'
```

 Pour activer l’utilisation de `SET TRANSACTION ISOLATION LEVEL SERIALIZABLE` uniquement dans la session en cours. 

**Example**  

```
EXECUTE sp_babelfish_configure 'isolation_level_serializable', 'pg_isolation'
```

 Pour permettre l’utilisation de `SET TRANSACTION ISOLATION LEVEL SERIALIZABLE` dans la session en cours et dans toutes les nouvelles sessions qui en découlent. 

**Example**  

```
EXECUTE sp_babelfish_configure 'isolation_level_serializable', 'pg_isolation', 'server'
```

 Pour désactiver l’utilisation de `SET TRANSACTION ISOLATION LEVEL SERIALIZABLE` dans la session en cours et dans les nouvelles sessions qui en découlent. 

**Example**  

```
EXECUTE sp_babelfish_configure 'isolation_level_serializable', 'off', 'server'
```

# Comparaison des niveaux d’isolement Babelfish et SQL Server
<a name="babelfish-transaction.examples"></a>

 Vous trouverez ci-dessous quelques exemples illustrant les nuances dans la manière dont SQL Server et Babelfish implémentent les niveaux d’isolement ANSI. 

**Note**  
Les niveaux d’isolement `REPEATABLE READ` et `SNAPSHOT` sont les mêmes dans Babelfish.
Les niveaux d’isolement `READ UNCOMMITTED` et `READ COMMITTED` sont les mêmes dans Babelfish.

L’exemple suivant montre comment créer la table de base pour tous les exemples mentionnés ci-dessous :

```
CREATE TABLE employee (
    id sys.INT NOT NULL PRIMARY KEY,
    name sys.VARCHAR(255)NOT NULL,
    age sys.INT NOT NULL
);
INSERT INTO employee (id, name, age) VALUES (1, 'A', 10);
INSERT INTO employee (id, name, age) VALUES (2, 'B', 20);
INSERT INTO employee (id, name, age) VALUES (3, 'C', 30);
```

**Topics**
+ [Comparaison de `READ UNCOMMITTED` dans Babelfish avec le niveau d’isolement `READ UNCOMMITTED` de SQL Server](#babelfish-transaction.examples.unc)
+ [Comparaison de `READ COMMITTED` dans Babelfish avec le niveau d’isolement `READ COMMITTED` de SQL Server](#babelfish-transaction.examples.com)
+ [Comparaison de `READ COMMITTED` dans Babelfish avec le niveau d’isolement `READ COMMITTED SNAPSHOT` de SQL Server](#babelfish-transaction.examples.snapshot)
+ [Comparaison de `REPEATABLE READ` dans Babelfish avec le niveau d’isolement `REPEATABLE READ` de SQL Server](#babelfish-transaction.examples.read)
+ [Comparaison de `SERIALIZABLE` dans Babelfish avec le niveau d’isolement `SERIALIZABLE` de SQL Server](#babelfish-transaction.examples.serialize)

## Comparaison de `READ UNCOMMITTED` dans Babelfish avec le niveau d’isolement `READ UNCOMMITTED` de SQL Server
<a name="babelfish-transaction.examples.unc"></a>

Le tableau suivant fournit des détails sur les lectures incorrectes lors de l’exécution de transactions simultanées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement `READ UNCOMMITTED` dans SQL Server par rapport à l’implémentation Babelfish.


| Transaction 1 | Transaction 2 | `READ UNCOMMITTED` dans SQL Server | `READ UNCOMMITTED` dans Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Aucun  |  Aucun  | 
|  `SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;`  |  `SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;`  |  Aucun  |  Aucun  | 
|  État Idle in transaction (Transaction inactive)  |  `UPDATE employee SET age=0;`  |  Mise à jour réussie.  |  Mise à jour réussie.  | 
|  État Idle in transaction (Transaction inactive)  |  `INSERT INTO employee VALUES (4, 'D', 40);`  |  Insertion réussie.  |  Insertion réussie.  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  La transaction 1 peut voir les modifications non validées de la transaction 2.  |  Comme `READ COMMITTED` dans Babelfish. Les modifications non validées de la transaction 2 ne sont pas visibles pour la transaction 1.   | 
|  État Idle in transaction (Transaction inactive)  |  `COMMIT`  |  Aucun  |  Aucun  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  Voit les modifications validées par la transaction 2.  |  Voit les modifications validées par la transaction 2.  | 

## Comparaison de `READ COMMITTED` dans Babelfish avec le niveau d’isolement `READ COMMITTED` de SQL Server
<a name="babelfish-transaction.examples.com"></a>

Le tableau suivant fournit des détails sur le comportement de blocage en lecture-écriture lorsque des transactions simultanées sont exécutées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement `READ COMMITTED` dans SQL Server par rapport à l’implémentation Babelfish.


| Transaction 1 | Transaction 2 | `READ COMMITTED` dans SQL Server | `READ COMMITTED` dans Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Aucun  |  Aucun  | 
|  `SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`  |  `SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`  |  Aucun  |  Aucun  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  Aucun  |  Aucun  | 
|  État Idle in transaction (Transaction inactive)  |  `UPDATE employee SET age=100 WHERE id = 1;`  |  Mise à jour réussie.  |  Mise à jour réussie.  | 
|  `UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);`  |  État Idle in transaction (Transaction inactive)  |  Étape bloquée jusqu’à ce que la transaction 2 soit validée.  |  Les modifications de la transaction 2 ne sont pas encore visibles. Met à jour la ligne avec id=3.  | 
|  État Idle in transaction (Transaction inactive)  |  `COMMIT`  |  La transaction 2 est validée avec succès. La transaction 1 est maintenant débloquée et voit la mise à jour de la transaction 2.  |  La transaction 2 est validée avec succès.   | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  La transaction 1 met à jour la ligne avec id = 1.  |  La transaction 1 met à jour la ligne avec id = 3.  | 

## Comparaison de `READ COMMITTED` dans Babelfish avec le niveau d’isolement `READ COMMITTED SNAPSHOT` de SQL Server
<a name="babelfish-transaction.examples.snapshot"></a>

Le tableau suivant fournit des détails sur le comportement de blocage des lignes nouvellement insérées lorsque des transactions simultanées sont exécutées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement `READ COMMITTED SNAPSHOT` dans SQL Server par rapport à l’implémentation de `READ COMMITTED` dans Babelfish.


| Transaction 1 | Transaction 2 | `READ COMMITTED SNAPSHOT` dans SQL Server | `READ COMMITTED` dans Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Aucun  |  Aucun  | 
|  `SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`  |  `SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`  |  Aucun  |  Aucun  | 
|  `INSERT INTO employee VALUES (4, 'D', 40);`  |  État Idle in transaction (Transaction inactive)  |  Aucun  |  Aucun  | 
|  État Idle in transaction (Transaction inactive)  |  `UPDATE employee SET age = 99;`  |  Étape bloquée jusqu’à ce que la transaction 1 soit validée. La ligne insérée est verrouillée par la transaction 1.  |  Trois lignes mises à jour. La ligne nouvellement insérée n’est pas encore visible.  | 
|  `COMMIT`  |  État Idle in transaction (Transaction inactive)  |  Validation réussie. La transaction 2 est désormais débloquée.  |  Validation réussie.  | 
|  État Idle in transaction (Transaction inactive)  |  `SELECT * FROM employee;`  |  Les 4 lignes ont le valeur age=99.  |  La ligne avec id = 4 a la valeur d’âge 40, car elle n’était pas visible pour la transaction 2 lors de la requête de mise à jour. Les autres lignes sont mises à jour avec age=99.   | 

## Comparaison de `REPEATABLE READ` dans Babelfish avec le niveau d’isolement `REPEATABLE READ` de SQL Server
<a name="babelfish-transaction.examples.read"></a>

Le tableau suivant fournit des détails sur le comportement de blocage en lecture-écriture lorsque des transactions simultanées sont exécutées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement `REPEATABLE READ` dans SQL Server par rapport à l’implémentation de `REPEATABLE READ` dans Babelfish.


| Transaction 1 | Transaction 2 | `REPEATABLE READ` dans SQL Server | `REPEATABLE READ` dans Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Aucun  |  Aucun  | 
|  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  Aucun  |  Aucun  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  Aucun  |  Aucun  | 
|  `UPDATE employee SET name='A_TXN1' WHERE id=1;`  |  État Idle in transaction (Transaction inactive)  |  Aucun  |  Aucun  | 
|  État Idle in transaction (Transaction inactive)  |  `SELECT * FROM employee WHERE id != 1;`  |  Aucun  |  Aucun  | 
|  État Idle in transaction (Transaction inactive)  |  `SELECT * FROM employee;`  |  La transaction 2 est bloquée jusqu’à ce que la transaction 1 soit validée.  |  La transaction 2 se déroule normalement.   | 
|  `COMMIT`  |  État Idle in transaction (Transaction inactive)  |  Aucun  |  Aucun  | 
|  État Idle in transaction (Transaction inactive)  |  `SELECT * FROM employee;`  |  La mise à jour de la transaction 1 est visible.  |  La mise à jour de la transaction 1 n’est pas visible.  | 
|  `COMMIT`  |  État Idle in transaction (Transaction inactive)  |  Aucun  |  Aucun  | 
|  État Idle in transaction (Transaction inactive)  |  `SELECT * FROM employee;`  |  voit la mise à jour de la transaction 1.  |  voit la mise à jour de la transaction 1.  | 

Le tableau suivant fournit des détails sur le comportement de blocage de l’écriture-écriture lorsque des transactions simultanées sont exécutées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement `REPEATABLE READ` dans SQL Server par rapport à l’implémentation de `REPEATABLE READ` dans Babelfish.


| Transaction 1 | Transaction 2 | `REPEATABLE READ` dans SQL Server | `REPEATABLE READ` dans Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Aucun  |  Aucun  | 
|  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  Aucun  |  Aucun  | 
|  `UPDATE employee SET name='A_TXN1' WHERE id=1;`  |  État Idle in transaction (Transaction inactive)  |  Aucun  |  Aucun  | 
|  État Idle in transaction (Transaction inactive)  |  `UPDATE employee SET name='A_TXN2' WHERE id=1;`  |  Transaction 2 bloquée.  |  Transaction 2 bloquée.  | 
|  `COMMIT`  |  État Idle in transaction (Transaction inactive)  |  La validation a été effectuée avec succès et la transaction 2 a été débloquée.  |  La validation a été effectuée avec succès et la transaction 2 échoue avec une erreur signalant que l’accès n’a pas pu être sérialisé en raison d’une mise à jour simultanée.  | 
|  État Idle in transaction (Transaction inactive)  |  `COMMIT`  |  Validation réussie.  |  La transaction 2 a déjà été abandonnée.  | 
|  État Idle in transaction (Transaction inactive)  |  `SELECT * FROM employee;`  |  La ligne avec id=1 contient name=’A\$1TX2’.  |  La ligne avec id=1 contient name=’A\$1TX1’.  | 

Le tableau suivant fournit des détails sur le comportement des lectures fantômes lorsque des transactions simultanées sont exécutées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement `REPEATABLE READ` dans SQL Server par rapport à l’implémentation de `REPEATABLE READ` dans Babelfish.


| Transaction 1 | Transaction 2 | `REPEATABLE READ` dans SQL Server | `REPEATABLE READ` dans Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Aucun  |  Aucun  | 
|  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  Aucun  |  Aucun  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  Aucun  |  Aucun  | 
|  État Idle in transaction (Transaction inactive)  |  `INSERT INTO employee VALUES (4, 'NewRowName', 20);`  |  La transaction 2 se déroule sans aucun blocage.  |  La transaction 2 se déroule sans aucun blocage.  | 
|  État Idle in transaction (Transaction inactive)  |  `SELECT * FROM employee;`  |  La ligne nouvellement insérée est visible.  |  La ligne nouvellement insérée est visible.  | 
|  État Idle in transaction (Transaction inactive)  |  `COMMIT`  |  Aucun  |  Aucun  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  La nouvelle ligne insérée par la transaction 2 est visible.  |  La nouvelle ligne insérée par la transaction 2 n’est pas visible.  | 
|  `COMMIT`  |  État Idle in transaction (Transaction inactive)  |  Aucun  |  Aucun  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  La ligne nouvellement insérée est visible.  |  La ligne nouvellement insérée est visible.  | 

Le tableau suivant fournit des détails lorsque des transactions simultanées sont exécutées, et indique les différents résultats finaux lors de l’utilisation du niveau d’isolement `REPEATABLE READ` dans SQL Server par rapport à l’implémentation Babelfish `REPEATABLE READ`.


| Transaction 1 | Transaction 2 | `REPEATABLE READ` dans SQL Server | `REPEATABLE READ` dans Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Aucun  |  Aucun  | 
|  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  Aucun  |  Aucun  | 
|  `UPDATE employee SET age = 100 WHERE age IN (SELECT MIN(age) FROM employee);`  |  État Idle in transaction (Transaction inactive)  |  La transaction 1 met à jour la ligne avec l’identifiant 1.  |  La transaction 1 met à jour la ligne avec l’identifiant 1.  | 
|  État Idle in transaction (Transaction inactive)  |  `UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);`  |  La transaction 2 est bloquée, car l’instruction SELECT tente de lire les lignes verrouillées par la requête UPDATE dans la transaction 1.  |  La transaction 2 se déroule sans aucun blocage, car la lecture n’est jamais bloquée, l’instruction SELECT s’exécute et la ligne avec id = 3 finira par être mise à jour, car les modifications de la transaction 1 ne sont pas encore visibles.  | 
|  État Idle in transaction (Transaction inactive)  |  `SELECT * FROM employee;`  |  Cette étape est exécutée une fois la transaction 1 validée. La ligne avec id = 1 est mise à jour par la transaction 2 à l’étape précédente et est visible ici.  |  La ligne avec id = 3 est mise à jour par la transaction 2.  | 
|  `COMMIT`  |  État Idle in transaction (Transaction inactive)  |  La transaction 2 est désormais débloquée.  |  Validation réussie.  | 
|  État Idle in transaction (Transaction inactive)  |  `COMMIT`  |  Aucun  |  Aucun  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  Les deux transactions exécutent la mise à jour sur la ligne contenant id = 1.  |  Les différentes lignes sont mises à jour par les transactions 1 et 2.  | 

## Comparaison de `SERIALIZABLE` dans Babelfish avec le niveau d’isolement `SERIALIZABLE` de SQL Server
<a name="babelfish-transaction.examples.serialize"></a>

Le tableau suivant fournit des détails sur les blocages de plage lorsque des transactions simultanées sont exécutées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement `SERIALIZABLE` dans SQL Server par rapport à l’implémentation de `SERIALIZABLE` dans Babelfish.


| Transaction 1 | Transaction 2 | `SERIALIZABLE` dans SQL Server | `SERIALIZABLE` dans Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Aucun  |  Aucun  | 
|  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  Aucun  |  Aucun  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  Aucun  |  Aucun  | 
|  État Idle in transaction (Transaction inactive)  |  `INSERT INTO employee VALUES (4, 'D', 35);`  |  La transaction 2 est bloquée jusqu’à ce que la transaction 1 soit validée.  |  La transaction 2 se déroule sans aucun blocage.  | 
|  État Idle in transaction (Transaction inactive)  |  `SELECT * FROM employee;`  |  Aucun  |  Aucun  | 
|  `COMMIT`  |  État Idle in transaction (Transaction inactive)  |  La transaction 1 est validée avec succès. La transaction 2 est désormais débloquée.  |  La transaction 1 est validée avec succès.   | 
|  État Idle in transaction (Transaction inactive)  |  `COMMIT`  |  Aucun  |  Aucun  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  La ligne nouvellement insérée est visible.  |  La ligne nouvellement insérée est visible.  | 

Le tableau suivant fournit des détails lorsque des transactions simultanées sont exécutées, et indique les différents résultats finaux lors de l’utilisation du niveau d’isolement `SERIALIZABLE` dans SQL Server par rapport à l’implémentation Babelfish `SERIALIZABLE`.


| Transaction 1 | Transaction 2 | `SERIALIZABLE` dans SQL Server | `SERIALIZABLE` dans Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Aucun  |  Aucun  | 
|  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  Aucun  |  Aucun  | 
|  État Idle in transaction (Transaction inactive)  |  `INSERT INTO employee VALUES (4, 'D', 40);`  |  Aucun  |  Aucun  | 
|  `UPDATE employee SET age =99 WHERE id = 4;`  |  État Idle in transaction (Transaction inactive)  |  La transaction 1 est bloquée jusqu’à ce que la transaction 2 soit validée.  |  La transaction 1 se déroule sans aucun blocage.  | 
|  État Idle in transaction (Transaction inactive)  |  `COMMIT`  |  La transaction 2 est validée avec succès. La transaction 1 est désormais débloquée.  |  La transaction 2 est validée avec succès.  | 
|  `COMMIT`  |  État Idle in transaction (Transaction inactive)  |  Aucun  |  Aucun  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  La ligne nouvellement insérée est visible avec une valeur d’âge = 99.  |  La ligne nouvellement insérée est visible avec une valeur d’âge = 40.  | 

Le tableau suivant fournit des informations détaillées lorsque vous exécutez une instruction `INSERT` dans une table avec une contrainte unique. Il montre les résultats observés lors de l’utilisation du niveau d’isolement `SERIALIZABLE` dans SQL Server par rapport à l’implémentation de `SERIALIZABLE` dans Babelfish.


| Transaction 1 | Transaction 2 | `SERIALIZABLE` dans SQL Server | `SERIALIZABLE` dans Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Aucun  |  Aucun  | 
|  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  Aucun  |  Aucun  | 
|  État Idle in transaction (Transaction inactive)  |  `INSERT INTO employee VALUES (4, 'D', 40);`  |  Aucun  |  Aucun  | 
|  `INSERT INTO employee VALUES ((SELECT MAX(id)+1 FROM employee), 'E', 50);`  |  État Idle in transaction (Transaction inactive)  |  La transaction 1 est bloquée jusqu’à ce que la transaction 2 soit validée.  |  La transaction 1 est bloquée jusqu’à ce que la transaction 2 soit validée.  | 
|  État Idle in transaction (Transaction inactive)  |  `COMMIT`  |  La transaction 2 est validée avec succès. La transaction 1 est désormais débloquée.  |  La transaction 2 est validée avec succès. La transaction 1 a été abandonnée avec une erreur de valeur de clé en double qui va à l’encontre de la contrainte unique.  | 
|  `COMMIT`  |  État Idle in transaction (Transaction inactive)  |  La transaction 1 est validée avec succès.  |  Les validations de la transaction 1 échouent, car l’accès n’a pas pu être sérialisé en raison de dépendances en lecture ou en écriture entre les transactions.  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  La ligne (5, ’E’, 50) est insérée.  |  Il n’existe que 4 lignes.  | 

Dans Babelfish, les transactions simultanées exécutées avec le niveau d’isolement serializable échouent avec une erreur d’anomalie de sérialisation si l’exécution de ces transactions est incompatible avec toutes les exécutions en série (une par une) possibles de ces transactions.

Les tableaux suivants fournissent des détails sur les anomalies de sérialisation lors de l’exécution de transactions simultanées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement `SERIALIZABLE` dans SQL Server par rapport à l’implémentation de `SERIALIZABLE` dans Babelfish.


| Transaction 1 | Transaction 2 | `SERIALIZABLE` dans SQL Server | `SERIALIZABLE` dans Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Aucun  |  Aucun  | 
|  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  Aucun  |  Aucun  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  Aucun  |  Aucun  | 
|  `UPDATE employee SET age=5 WHERE age=10;`  |  État Idle in transaction (Transaction inactive)  |  Aucun  |  Aucun  | 
|  État Idle in transaction (Transaction inactive)  |  `SELECT * FROM employee;`  |  La transaction 2 est bloquée jusqu’à ce que la transaction 1 soit validée.  |  La transaction 2 se déroule sans aucun blocage.  | 
|  État Idle in transaction (Transaction inactive)  |  `UPDATE employee SET age=35 WHERE age=30;`  |  Aucun  |  Aucun  | 
|  `COMMIT`  |  État Idle in transaction (Transaction inactive)  |  La transaction 1 est validée avec succès.  |  La transaction 1 est validée en premier et peut être validée avec succès.  | 
|  État Idle in transaction (Transaction inactive)  |  `COMMIT`  |  La transaction 2 est validée avec succès.  |  La validation de la transaction 2 échoue avec une erreur de sérialisation, l’ensemble de la transaction a été annulée. Réessayez la transaction 2.  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  Les modifications apportées par les deux transactions sont visibles.  |  La transaction 2 a été annulée. Seules les modifications de la transaction 1 sont visibles.  | 

Dans Babelfish, l’anomalie de sérialisation n’est possible que si toutes les transactions simultanées s’exécutent au niveau d’isolement `SERIALIZABLE`. Dans le tableau suivant, prenons l’exemple ci-dessus, mais définissons plutôt la transaction 2 sur le niveau d’isolement `REPEATABLE READ`.


| Transaction 1 | Transaction 2 | Niveaux d’isolement SQL Server | Niveaux d’isolement Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Aucun  |  Aucun  | 
|  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  Aucun  |  Aucun  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  Aucun  |  Aucun  | 
|  `UPDATE employee SET age=5 WHERE age=10;`  |  État Idle in transaction (Transaction inactive)  |  Aucun  |  Aucun  | 
|  État Idle in transaction (Transaction inactive)  |  `SELECT * FROM employee;`  |  La transaction 2 est bloquée jusqu’à ce que la transaction 1 soit validée.  |  La transaction 2 se déroule sans aucun blocage.  | 
|  État Idle in transaction (Transaction inactive)  |  `UPDATE employee SET age=35 WHERE age=30;`  |  Aucun  |  Aucun  | 
|  `COMMIT`  |  État Idle in transaction (Transaction inactive)  |  La transaction 1 est validée avec succès.  |  La transaction 1 est validée avec succès.  | 
|  État Idle in transaction (Transaction inactive)  |  `COMMIT`  |  La transaction 2 est validée avec succès.  |  La transaction 2 est validée avec succès.  | 
|  `SELECT * FROM employee;`  |  État Idle in transaction (Transaction inactive)  |  Les modifications apportées par les deux transactions sont visibles.  |  Les modifications apportées par les deux transactions sont visibles.  |