Autocommit – avec contrôle !

définir l’attribut d’autocommit indépendamment du niveau d’isolation utilisé. Cette indépendance permet de choisir le niveau d’isolation correct pour une application donnée, indépendamment du paramétrage d’autocommit. Une fois le niveau d’isolation choisi, on peut décider si l’application devra contrôler explicitement les commits et les rollbacks, en désactivant autocommit ou en confiant la responsabilité d’autocommit à  DB2, en validant autocommit.

Le fait de laisser spécifier un niveau d’isolation pendant qu’autocommit est validé apporte à  l’application la protection du contrôle de commitment, mais sans exiger de l’application qu’elle inclue des opérations de commit et de rollback, parce que le moteur de la base de données n’est pas responsable de cet aspect des choses.

On peut même valider autocommit avec un niveau d’isolation No Commit. Cette combinaison n’exige pas la journalisation des tables et permet d’utiliser des localisateurs LOB. Elle permet également au programme appelant de « commit » les modifications apportées par des procédures stockées et des triggers, même si le programme appelant n’utilise pas le contrôle de commitment. (Remarque : C’est souvent discutable. Tout d’abord, presque toutes les tables doivent être journalisées. Ensuite, si l’application a besoin d’une certaine forme d’isolation ou de reprise de transactions, elle devra utiliser l’un des niveaux d’isolation disponibles.)

IBM aurait pu mettre en oeuvre autocommit en ordonnant au moteur de DB2 UDB de toujours émettre un commit dès l’exécution de toute instruction SQL. Cette méthode est simple et aurait fonctionné correctement, mais elle ne serait pas très efficace parce que de nombreuses requêtes SQL n’apportent aucune modification aux données. Ainsi, une séquence consistant à  ouvrir un curseur SQL, a atteindre des milliers de lignes, puis à  fermer le curseur, est très courante. Si une opération de commit supplémentaire avait lieu à  chaque exécution de cette séquence courante, le programme rendrait de nombreuses visites au moteur de DB2 UDB, bien qu’aucune modification n’ait besoin de commit, et les performances en souffriraient.

C’est pourquoi IBM a mis en oeuvre le support d’autocommit de telle sorte que DB2 UDB n’émette un commit que dans un cas : après bonne fin d’une instruction SQL dans laquelle des modifications ont été effectuées sous le contrôle de commitment.

Pour cela, DB2 UDB examine une structure interne (block commit) pour voir si des modifications sont en attente ou si la transaction a acquis des verrouillages de lignes. Cela peut se faire rapidement et à  une fraction du coût d’un commit réel. Si aucune modification en suspens ou verrouillage de lignes ne sont journalisés dans la structure, le commit n’est pas émis. Ce traitement fonctionne pour l’accès à  des bases de données locales et distantes.

Dans certains cas, le nouveau support d’autocommit modifie quelques exigences de journalisation. Comme l’ancienne implémentation d’autocommit mettait simplement sur off le contrôle de commitment (*NONE ou *NC), les tables n’avaient pas besoin d’être journalisées. Désormais, si l’application n’a toujours pas besoin d’utiliser les niveaux d’isolation des transactions mais que l’on veuille bénéficier des avantages supplémentaires d’autocommit, on peut mettre autocommit sur on avec le niveau d’isolation No Commit pour éviter d’avoir à  journaliser des tables. En revanche, si on valide autocommit en utilisant un niveau d’isolation autre que No Commit, toute table modifiée par l’application doit être journalisée. Les tables auxquelles on accède en utilisant des requêtes en lecture seule n’ont pas besoin d’être journalisées.