Avant d’examiner les types d’isolement, nous devons comprendre :

Qu’est-ce que le niveau d’isolement et pourquoi en avons-nous besoin ?

Différentes applications ou utilisateurs peuvent accéder et modifier les données stockées dans une base de données DB2 en même temps. Le gestionnaire de base de données DB2 doit donc pouvoir permettre aux utilisateurs d’apporter les modifications nécessaires tout en garantissant que l’intégrité des données n’est jamais compromise.

Le partage de ressources DB2 par plusieurs utilisateurs ou programmes d’application en même temps est appelé concurrence. L’une des façons dont DB2 applique la simultanéité consiste à utiliser des niveaux d’isolement, qui déterminent comment les données consultées et/ou modifiées par une transaction sont “isolées” des autres transactions.

Les niveaux d’isolement sont appliqués par des verrous et le type de verrou utilisé limite ou empêche l’accès aux données par des processus d’application simultanés.

Le gestionnaire de base de données prend en charge trois catégories générales de verrous :

Share (S) : 
Sous un verrou S, les processus d’application simultanés sont limités aux opérations en lecture seule sur les données.

Update (U) :
Sous un verrou U, les processus applicatifs concurrents sont limités aux opérations en lecture seule sur les données, si ces processus n’ont pas déclaré qu’ils pourraient mettre à jour une ligne. Le gestionnaire de base de données suppose que le processus qui examine actuellement une ligne peut la mettre à jour.

Exclusive (X) :
Sous un verrou X, les processus d’application simultanés ne peuvent en aucun cas accéder aux données. Cela ne s’applique pas aux processus d’application avec un niveau d’isolement de lecture non validée (UR), qui peut lire mais pas modifier les données.

Quel que soit le niveau d’isolement, le gestionnaire de base de données place des verrous exclusifs sur chaque ligne insérée, mise à jour ou supprimée. Ainsi, tous les niveaux d’isolement garantissent que toute ligne modifiée par un processus d’application au cours d’une unité de travail n’est pas modifiée par un autre processus d’application tant que l’unité de travail n’est pas terminée.

DB2 a quatre niveaux d’isolement de verrouillage :

Lecture répétable (RR) :

Cela maintient les verrous de page et de ligne jusqu’à ce qu’un point COMMIT soit atteint. Aucun autre programme ne peut modifier les données. Si les données sont consultées deux fois au cours de l’unité de travail, les mêmes données exactes seront renvoyées.

Stabilité de la lecture (RS):

Cela maintient les verrous de page et de ligne jusqu’à ce qu’un point COMMIT soit atteint. Mais d’autres programmes peuvent INSÉRER de nouvelles données. Si les données sont accédées deux fois au cours de l’unité de travail, de nouvelles lignes peuvent être renvoyées, mais les anciennes lignes n’auront pas changé.

Stabilité du curseur (CS) :

Niveau d’isolement par défaut. Cela acquiert et libère les verrous de page ou de ligne au fur et à mesure que les pages ou les lignes sont lues et traitées. Cela fournit le plus haut niveau de simultanéité. Mais il est possible que des données différentes soient renvoyées par le même curseur s’il est traité deux fois au cours de la même unité de travail.

Lecture non validée (UR) :

Ceci est également connu sous le nom de traitement de lecture sale. UR évite complètement le verrouillage. Il est possible de lire des données qui n’existent peut-être jamais réellement dans la base de données. Nous pouvons l’utiliser pour travailler avec la table qui est rarement mise à jour.

Quel que soit le niveau d’ISOLEMENT choisi, tous les verrous de page sont libérés lorsqu’un COMMIT est rencontré.