> Tech > Nouveau support d’autocommit pour DB2 UDB

Nouveau support d’autocommit pour DB2 UDB

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Mark Megerian et Kent Milligan
Sur l'iSeries, une transaction de base de données commence implicitement dès l'instant où une donnée quelconque est lue ou écrite, et elle se termine par une demande de commit ou de rollback ultérieure. Ceux qui ont déjà  utilisé l'un des jeux API de type SQL (ODBC, JDBC, CLI) pour la programmation de base de données, ont certainement remarqué un mode appelé autocommit ou automatic commit...

Cette option était destinée aux programmeurs qui ne veulent pas écrire du code pour émettre des commits, mais préfèrent laisser à  la base de données le soin de faire un commit automatique des modifications apportées à  la base de données.

L'utilisation d'autocommit présente des risques parce que l'on n'obtient pas la protection « tout ou rien » du commitment control ou la possibilité de recourir à  des niveaux d'isolation de transactions plus élevés. De plus, un nouveau programmeur peut fort bien ajouter une nouvelle modification de base de données à  une application existante, sans espérer que cette modification sera « committed » automatiquement.

Heureusement, des améliorations récentes de l'option autocommit dans les versions V4R4 et V4R5 règlent ces problèmes ainsi que d'autres lacunes des versions d'autocommit antérieures. Nous verrons ces améliorations dans un moment. Pour l'instant, voyons pourquoi elles sont nécessaires

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.)

Téléchargez cette ressource

Comment lutter contre le Phishing ?

Comment lutter contre le Phishing ?

Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.

Tech - Par iTPro.fr - Publié le 24 juin 2010