Décrire les niveaux d’isolation
PostgreSQL a trois niveaux d’isolation des transactions qui empêchent trois types de conflits d’accès concurrentiel : les lectures incorrectes, les lectures non reproductibles et les lectures fantômes.
Types de conflits d’accès concurrentiel
Lectures erronées
Une lecture erronée se produit lorsqu’une transaction lit la version mise à jour de données qu’une autre transaction est en train de modifier. Toutefois, cette mise à jour n’est jamais validée.
Par exemple, une transaction se produit sur un compte d’épargne qui résulterait en un solde de compte négatif. Avant la validation de la transaction, le solde du compte est vérifié et la transaction est annulée, car les comptes d’épargne ne peuvent pas avoir de soldes négatifs. En même temps, un rapport est exécuté pour afficher le solde actuel de tous les comptes d’épargne. Si les lectures erronées sont autorisées, le solde négatif est retourné, même s’il n’est jamais validé.
Lectures non renouvelées
Une lecture non renouvelable se produit si une transaction lit des données, si ces données sont mises à jour par une autre transaction et si la transaction initiale lit à nouveau les données et voit les nouvelles mises à jour.
Par exemple, la Connexion A démarre une transaction qui lit le coût par unité et le nombre d’unités d’une commande, à savoir un coût de 10 et un nombre d’unités de 3. La Connexion B démarre ensuite une autre transaction et met à jour la même commande pour définir le coût par unité sur 12. Dans la même transaction que la requête d’origine, la Connexion A calcule le coût total de la commande. Si les lectures non renouvelées sont autorisées, la Connexion A retourne le coût par unité de 10, le nombre d’unités de 3 et le coût total de 36, ce qui n’a évidemment aucun sens.
Lectures fantômes.
Une lecture fantôme se produit si une transaction lit des données, si une autre transaction ajoute une nouvelle ligne (ou plusieurs lignes) aux données et si la transaction initiale lit à nouveau les données et voit les nouvelles mises à jour.
Par exemple, la Connexion A démarre une transaction et compte le nombre total de factures du jour à Paris. Le décompte totalise 1100 factures pour l’ensemble des 10 magasins à Paris. La Connexion B démarre ensuite une autre transaction et ajoute un nouveau magasin à Paris avec 200 factures lors de son jour d’ouverture. Dans la transaction de la Connexion A, le système compte désormais le nombre de magasins pour calculer le nombre de factures par magasin. La Connexion A divise désormais les 1100 transactions par 11 magasins, plutôt que par les 10 d’origine qui existaient lors de l’exécution de la requête du nombre de factures. Ce calcul retourne maintenant une moyenne erronée de 100, même si le nouveau magasin avait 200 factures dont la transaction de la Connexion A n’a pas tenu compte dans son calcul de moyenne.
Niveaux d'isolement
Azure Database pour PostgreSQL a trois niveaux d’isolation des transactions : de lecture validée, de lecture renouvelée et sérialisable. La lecture non validée n’est pas disponible dans Azure Database pour PostgreSQL.
Comment les niveaux d’isolation affectent les conflits d’accès concurrentiel :
| Niveau d'isolation | Lecture incorrecte | Lecture non renouvelée | Lecture fantôme |
|---|---|---|---|
| Lecture non validée* | Possible | Possible | Possible |
| Lecture validée | Impossible | Possible | Possible |
| Lecture renouvelable | Impossible | Impossible | Possible |
| Sérialisable | Impossible | Impossible | Impossible |
* Non disponible dans PostgreSQL
La lecture validée est le niveau d’isolation par défaut dans Azure Database pour PostgreSQL. La lecture validée est la plus appropriée pour la plupart des scénarios, car elle empêche les lectures erronées tout en offrant de bonnes performances. Il est possible d’obtenir des lectures non renouvelées et fantômes, mais elles ne peuvent se produire que s’il existe plusieurs instructions SELECT qui interrogent simultanément les mêmes données.
La lecture renouvelée diffère de la lecture validée, car plusieurs instructions SELECT dans une transaction donneraient les mêmes résultats, même si une autre transaction mettait à jour les lignes entre l’exécution des deux instructions SELECT de la transaction. Si une autre transaction insère de nouvelles lignes, celles-ci n’apparaîtront pas dans les résultats de la deuxième instruction SELECT.
Le niveau d’isolation sérialisable fournit le niveau d’isolation des transactions le plus élevé et agit comme si différentes transactions étaient exécutées en série, c’est-à-dire l’une après l’autre. Le niveau d’isolation sérialisable présent un inconvénient notable : si une transaction effectue une mise à jour, d’autres transactions peuvent la bloquer. La transaction sérialisable doit attendre la fin de la transaction bloquante, ce qui influence la performance.
Les transactions sérialisables ne peuvent pas non plus apporter de modifications à des lignes modifiées par d’autres transactions pendant la transaction sérialisable. Si cette forme de conflit se produit, un message d’erreur est retourné, et il est donc important qu’une logique de nouvelle tentative soit intégrée aux applications lorsque des transactions sérialisables sont utilisées.
Pour mettre à jour les niveaux d’isolation des transactions, utilisez la commande TRANSACTION ISOLATION LEVEL au sein d’une transaction.
Par exemple :
BEGIN TRANSACTION
TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT * FROM humanresources.department
COMMIT;