L'option ISOLATION (CS)
L'option ISOLATION (CS) ou stabilité du curseur permet une simultanéité maximale avec l'intégrité des données. Avec l'option ISOLATION (CS), une transaction ne bloque que ses modifications non validées et la ligne courante de chacun de ses curseurs.
Cependant, après que le processus a quitté une ligne ou une page, un autre processus peut modifier les données. Avec CURRENTDATA(NO), le processus n'a pas besoin de quitter une ligne ou une page pour permettre à un autre processus de modifier les données. Si le premier processus revient pour lire la même ligne ou la même page, les données ne sont pas nécessairement les mêmes. Considérez les conséquences suivantes de cette éventualité :
- Pour les espaces de table créés avec LOCKSIZE ROW, PAGE ou ANY, un changement peut se produire même lors de l'exécution d'une seule instruction SQL qui lit la même ligne plusieurs fois. Dans l'instruction suivante, les données lues par le SELECT interne peuvent être modifiées par une autre transaction avant d'être lues par le SELECT externe.
Par conséquent, les informations renvoyées par cette requête peuvent provenir d'une ligne qui n'est plus celle ayant la valeur maximale pour C1.SELECT * FROM T1 WHERE C1 = (SELECT MAX(C1) FROM T1); - Un autre cas est un processus qui lit une ligne et revient plus tard pour la mettre à jour. Cette ligne peut ne plus exister ou ne pas exister dans l'état où elle se trouvait lorsque votre processus de candidature a lu la ligne à l'origine. En d'autres termes, une autre application a peut-être supprimé ou mis à jour la ligne. Si votre application effectue des opérations non liées au curseur sur une ligne située sous le curseur, assurez-vous que l'application peut tolérer des conditions
non trouvées
.De même, supposons qu'une autre application mette à jour une ligne après qu'elle ait été lue par votre application. Si votre application revient plus tard pour mettre à jour la ligne en fonction de la valeur lue, votre application efface la mise à jour de la deuxième application.
Par conséquent, si vous utilisez ISOLATION(CS) avec la mise à jour, votre processus devra peut-être verrouiller les mises à jour simultanées. Une méthode consiste à déclarer un curseur avec la clause FOR UPDATE.
Pour les packages et les plans contenant des curseurs statiques défilants pouvant être mis à jour, ISOLATION(CS) permet à l' Db2 , d'utiliser un contrôle de concurrence optimiste. Db2 peut utiliser un contrôle de concurrence optimiste pour réduire la durée de maintien des verrous dans les situations suivantes :
- Entre deux opérations de récupération consécutives
- Entre les opérations de récupération et les opérations ultérieures de mise à jour ou de suppression positionnées
Db2 ne peut pas utiliser le contrôle de concurrence optimiste pour les curseurs dynamiques défilants. Avec les curseurs dynamiques défilants, la dernière ligne ou page extraite de la table de base reste verrouillée pour maintenir sa position en vue d'une mise à jour ou d'une suppression positionnée.
Les deux figures suivantes montrent le traitement des opérations de mise à jour et de suppression positionnées sans contrôle de concurrence optimiste et avec contrôle de concurrence optimiste.
Le contrôle optimiste des accès simultanés se compose des étapes suivantes :
- Lorsque l'application demande une opération de récupération pour positionner le curseur sur une ligne, l' Db2 e verrouille cette ligne, exécute l'opération de récupération et libère le verrou.
- Lorsque l'application demande une opération de mise à jour ou de suppression positionnée sur la ligne, Db2 effectue les étapes suivantes :
- Verrouille la ligne.
- Réévalue le prédicat pour s'assurer que la ligne est toujours admissible dans la table de résultats.