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
Une question d’intégrité : guide pratique des transactions sur bases de données
Le contrôle de commitment supporte des transactions qui mettent à jour les tables de bases de données, y compris les tables SQL et les fichiers physiques créés avec la commande CL CrtPf. (Au niveau du système d’exploitation, une table SQL est juste un fichier physique à un seul membre.) Bien que le contrôle de commitment i5/OS supporte également d’autres types d’objets de transaction, cet article ne s’intéresse qu’aux tables de bases de données.
Quand une transaction met à jour plusieurs lignes dans une ou plusieurs tables (c’est-à-dire des enregistrements dans des fichiers physiques), une application devrait généralement s’assurer que toutes les lignes sont mises à jour ou qu’aucune d’elles ne l’est. L’exemple classique est une transaction bancaire visant à transférer une certaine somme du compte épargne au compte chèques. L’application effectuerait généralement deux mises à jour :
• L’une pour réduire le solde actuel dans la ligne qui contient les données du compte épargne,
• L’autre pour augmenter le solde actuel dans le ligne qui contient les données du compte chèques.
En cas d’échec de l’application ou du système après la première mise à jour, mais avant la seconde, la base de données ne contiendrait plus une information exacte.
Grâce au contrôle de commitment, une application peut garantir que les deux mises à jour se produisent, ou aucune. En substance, une application soumise au contrôle de commitment déroule la logique suivante :
Update savings table
If error { Rollback }
else { Update checking table
If error { Rollback }
else { Commit }
Si tout se déroule normalement, quand les deux lignes ont été bien mises à jour, l’opération Commit rend permanents les changements de la base de données. En revanche, si l’une des mises à jour échoue, l’opération Rollback rétablit les mises à jour effectuées pendant la transaction partiellement réalisée. Plus important, si l’application se termine de façon anormale ou si le job ou tout le système se termine de façon anormale, le système rétablira automatiquement toutes les mises à jour de bases de données pour les transactions « uncommitted ». Le contrôle de commitment fournit une bonne intégrité des transactions (toutes ou aucune), indépendamment du langage de programmation ou du fait que vos applications utilisent SQL ou le RLA (record-level access) traditionnel pour les opérations base de données.
Le contrôle de commitment peut également traiter toutes sortes de transactions : simultanées, multilignes, multitables et même à distance. Pour obtenir l’atomicité des transactions dans les applications de gestion, je conseille fortement le contrôle de commitment de type i5 parce que les créations maison n’offrent pas le même niveau de garantie ou de facilité de reprise.
Téléchargez cette ressource
Sécuriser votre système d’impression
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
