Niveaux d’isolation

transaction est None. Ce niveau peut être défini de plusieurs manières, comme le montre la figure 1 (voir aussi l’encadré « Conseil RPG: Attention aux ODP simultanés »).
Voici la description des caractéristiques générales de chaque niveau d’isolation.

None. Avec ce niveau, le contrôle de commitment est inactif et on a une protection minimale contre des mises à jour conflictuelles. Dans une application sans contrôle de commitment, chaque mise à jour de ligne est effectivement « committed » au moment où elle est effectuée et il n’y a aucune possibilité de rollback ou reprise de transaction. Un job s’exécutant sans contrôle de commitment peut extraire des lignes qui ont été changées – mais pas encore « committed » — par un autre job. Ce sont de « mauvaises lectures » parce qu’elles peuvent lire des données qui feront par la suite l’objet d’un rollback par l’autre job. D’une manière générale, ce niveau d’isolation est déconseillé sauf pour des applications en lecture seule quand un verrou d’objet adéquat est maintenu sur une table pour la protéger contre des mises à jour conflictuelles de la part d’un autre job.

Read Uncommitted. C’est le niveau d’isolation le plus bas. Il supporte le mode « toutes ou aucune » transaction du contrôle de commitment, y compris les opérations commit/ rollback et la reprise des transactions. Ce niveau permet encore de mauvaises lectures (dirty reads), donc il ne faut l’utiliser que dans deux cas : quand l’application ne souffrira pas si elle lit des changements qui font par la suite l’objet d’un rollback, ou quand l’application obtient un verrou d’objet approprié pour éviter les conflits. Sur une instruction SQL Set Transaction Isolation Level, vous devez aussi spécifier les mots-clés Read Write, en même temps que Read Uncommitted, si vous voulez pouvoir exécuter des instructions Insert, Update ou Delete.

Read Committed. Ce niveau d’isolation empêche une application de lire des données uncommitted. C’est le niveau d’isolation minimum acceptable, à moins d’utiliser aussi le verrouillage d’objet. Attention tout de même aux applications qui pourraient extraire des lignes (qui n’ont pas été mises à jour) dans la même transaction. Avec le niveau d’isolation Read Committed, un job peut obtenir des résultats différents quand il extrait une ligne, parce qu’il peut voir les changements committed (par un autre job) apportés aux lignes qui ne sont pas mises à jour dans la transaction.

Repeatable Read. Une application tournant à ce niveau a la garantie de toujours voir le même contenu pour toute ligne qu’elle extrait plus d’une fois dans la même transaction. Mais il se peut qu’un jeu de résultats de requête (par exemple tous les clients de Marseille) contienne des lignes supplémentaires si la requête est réexécutée dans la même transaction. Avec Repeatable Read, d’autres jobs sont autorisés à insérer de nouvelles lignes (appelées aussi « lignes fantômes ») dans la plage d’une requête effectuée par un autre job fonctionnant au même niveau d’isolation Repeatable Read.

Serializable. Ce niveau d’isolation ne peut être instauré qu’au moyen de SQL. Il garantit que des transactions simultanées produiront les mêmes résultats que si chacune d’elles était exécutée séparément (c’est-à-dire en série, l’une après l’autre). Toute requête répétée dans une transaction extraira toujours les mêmes lignes avec le même contenu. SQL garantit cela en plaçant un verrou d’objet approprié sur une table accédée dès qu’une requête quelconque fait référence à la table. Le verrou d’objet est levé quand la transaction fait l’objet d’un commit ou d’un rollback.

Le niveau de verrou en vigueur quand on spécifie Serializable dépend de la release OS/400 ou i5/OS. Pour les releases V5R1 et antérieures, Serializable utilise le même niveau d’isolation de verrou de contrôle de commitment (*All) que le niveau d’isolation Repeatable Read. Pour la V5R2 et versions ultérieures, les requêtes qui utilisent le nouveau moteur de requête SQL peuvent utiliser un niveau de verrouillage inférieur (par exemple, *Chg ou *CS). Le système peut utiliser un niveau de verrouillage inférieur parce que Serializable place un verrou d’objet sur la totalité de la table (membre de fichier).

Dans le choix du niveau d’isolation, évitez la tentation de retenir immédiatement Serializable tout simplement parce qu’il garantit le mieux qu’un autre job n’interfèrera pas avec les transactions de votre application. En effet, en adoptant des niveaux d’isolation plus puissants, on augmente aussi le risque d’un genre d’interférences différent causées par des verrous de lignes ou d’objets conflictuels.

En règle générale, la plupart des applications devraient utiliser les niveaux d’isolation Read Committed ou Repeatable Read, selon qu’elles extraient ou non des lignes dans la même transaction. (Pour des informations plus précises sur le fonctionnement des différents niveaux d’isolation et pour examiner de plus près la durée des verrous de lignes et la compatibilité de différentes sortes d’opérations d’I/O simultanées sous le contrôle de commitment, voir le chapitre 13 du SQL/400 Developer’s Guide)