Une question d’intégrité : guide pratique des transactions sur bases de données

Le traitement transactionnel est au coeur de la plupart des applications i5. Une application est une opération logique unique qui consiste généralement à lire ou à mettre à jour une ou plusieurs tables de bases de données (plus banalement, des fichiers). Quelle que soit l’action des utilisateurs : saisir des commandes, planifier des réservations d’hôtel, ou exécuter des transactions financières, une application doit être conçue de telle sorte que toutes les transactions satisfassent au test « ACID »« ACID » :
• Atomicité (Atomicity) : Tous les effets d’une transaction réussissent ou tous échouent.
• Cohérence (Consistency) : La base de données reste dans un état cohérent vis-à-vis de ses règles d’intégrité, et cela qu’une transaction s’exécute correctement ou échoue.
• Isolation : Les effets d’une transaction sont isolés des effets des transactions effectuées au même moment par d’autres applications et utilisateurs.
• Durabilité (Durability) : Les effets d’une transaction bien « committed » persistent même en cas de défaillance du système.

Sans la puissance et la sophistication de i5/OS et de DB2, il serait pratiquement impossible de s’assurer que les applications remplissent tous les critères ACID. Heureusement, il est facile d’effectuer des transactions fiables sur le i5 quand les applications bénéficient de la journalisation et du contrôle de commitment : deux fonctions intégrées dans l’architecture i5 depuis le S/38.

Deux de ces critères, la cohérence et la durabilité, sont plutôt simples et assurés automatiquement, pour la plupart, par DB2. Pour maintenir la cohérence de la base de données, DB2 rejette les mises à jour qui violent les contraintes suivantes d’une table : clé primaire, unique, clé étrangère, ou vérification. Les développeurs d’applications n’ont que deux choses à faire :

• Définir les contraintes appropriées sur l’instruction Create Table SQL ou sur la commande CL Add Physical File Contrainst (AddPfCst).
• Ajouter le code applicatif nécessaire pour détecter et traiter les erreurs d’I/O, y compris les violations de contraintes.

La durabilité est instaurée quand une table est journalisée: c’est ce qui se passe par défaut quand on crée une table avec une instruction SQL Create Table. On peut aussi utiliser la commande CL JrnPf pour journaliser une table (ou un fichier physique non-SQL). Quand une table est journalisée, le système écrit une entrée dans un récepteur du journal et l’envoie de force en stockage auxiliaire avant que la table de base de données associée ne soit physiquement modifiée. Quand une table est ouverte sous le contrôle de commitment, le système écrit aussi les entrées du journal pour les opérations commit et rollback.

Si une table est endommagée, vous pouvez récupérer ses mises à jour en restaurant la table à l’aide de la sauvegarde la plus récente puis en appliquant les entrées du journal pour amener la table au niveau de la dernière opération de mise à jour ou de la dernière transaction « committed ». La journalisation des tables est une bonne pratique que l’on devrait appliquer systématiquement pour la plupart des tables de base de données. (Vous trouverez de la documentation sur la journalisation dans la rubrique Systems ManagementIJournal Management dans le V5R4 Information Center.) DB2 prend aussi en charge le principe de « toutes ou aucune » transactions (c’est-à-dire l’atomicité) et plusieurs niveaux d’isolation des transactions. Bien que ce soient des aspects distincts du support des transactions, sur l’i5 ils sont tous assurés par l’environnement de contrôle de commitment i5/OS. Le contrôle de commitment, à son tour, compte sur la journalisation pour garantir le principe « toutes ou aucune » tra