Nouveau support d’autocommit pour DB2 UDB

Dans les versions antérieures de l’OS/400, l’option autocommit permettait essentiellement aux applications d’effectuer toutes les opérations d’I/O sans un environnement de contrôle de commitment. Ainsi, les applications ODBC qui accédaient aux données iSeries avec autocommit activé, fonctionnaient de la même manière que des programmes d’écran passif n’utilisant pas le contrôle de commitment. Dans les deux types d’applications, DB2 Universal Database (DB2 UDB) traitait chaque requête de base de données comme une transaction distincte – sans que l’application puisse directement défaire (annuler rétroactivement) une modification de base de données, ou grouper de multiples opérations de base de données dans une seule transaction. Pour avoir des possibilités de reprise de base de données complètes, une application devrait utiliser le contrôle de commitment en précisant un niveau d’isolation de transactions (c’est-à -dire, un niveau de verrouillage du contrôle de commitment autre que *NONE).

Notons que l’isolation level en SQL est comparable à  un lock level de contrôle de commitment de l’OS/400. Nous utilisons la terminologie SQL dans la plupart des cas. La figure 1 montre la correspondance entre ces termes.

Outre le fait de limiter les possibilités de reprise de base de données des applications, l’ancienne implémentation autocommit de l’iSeries présentait plusieurs autres effets secondaires désagréables pour les applications et certains utilitaires. Par exemple :
· Une application utilisant autocommit ne pouvait pas appeler une procédure cataloguée SQL définie avec la syntaxe BEGIN ATOMIC.
· Une application utilisant autocommit ne pouvait pas appeler une procédure cataloguée qui avait émis une instruction commit ou rollback.
· Tout changement de base de données effectué dans une procédure cataloguée, fonction ou trigger qui s’exécutait sous le contrôle de commitment était automatiquement annulé rétroactivement.
· Une application utilisant autocommit ne pouvait pas émettre un commit ou un rollback à  partir du SQL Script Center d’Operations Navigator.
· Une application utilisant autocommit ne pouvait pas utiliser des localisateurs de LOB (large object)

Certaines de ces lacunes – particulièrement, l’annulation rétroactive (rollback) automatique des modifications de bases de données effectuées par les procédures cataloguées et les triggers – avaient un impact négatif sur les applications. C’est pourquoi, dans la V4R5, IBM a amélioré la mise en oeuvre d’autocommit de l’iSeries pour les éliminer. IBM a également offert ces améliorations sur la V4R4 avec le PTF V4R4 Database Group (SF99104), diffusé cette année.

Comme IBM a apporté les améliorations d’autocommit dans le moteur de la base de données DB2 UDB, les applications existantes n’ont pas besoin de modifications pour utiliser le support autocommit amélioré. Ce basculement automatique sur le nouveau support autocommit peut créer de nouvelles exigences de journalisation pour une application – nous y reviendrons dans un moment. Pour l’instant, voyons sous le capot des améliorations d’autocommit apportées au moteur de base de données DB2 UDB. (Remarque : comme les drivers Client Access Express ODBC et iSeries Java Toolbox JDBC ne sont pas en interface directe avec le moteur DB2 UDB, ils ne bénéficient pas de toutes les modifications apportées au moteur de la base de données. Nous nous intéresserons aux restrictions d’autocommit pour les drivers ODBC et JDBC dans un instant.)