Ce chapitre décrit la fonction de mise à jour multisite qui est utilisée dans les procédures faisant intervenir des serveurs de bases de données hôte et AS/400. Il décrit les produits et composants nécessaires à la mise en oeuvre d'applications PC, UNIX et Web permettant la mise à jour de plusieurs bases de données DB2 au cours d'une même transaction.
La mise à jour multisite (également appelée unité d'oeuvre répartie [DUOW] ou validation en deux phases) est une fonction permettant à vos applications de mettre à jour des données sur plusieurs serveurs de bases de données éloignés en garantissant leur intégrité. La mise à jour multisite peut, par exemple, prendre la forme d'une transaction bancaire impliquant un transfert d'argent d'un compte vers un autre, les deux comptes se trouvant sur des serveurs de bases de données différents.
Au cours de ce type de transaction, il est essentiel que l'opération de débit d'un compte ne soit validée que lorsque l'opération de crédit sur l'autre compte est elle-même validée. La fonction de mise à jour multisite intervient lorsque les données relatives à ces comptes sont gérées par deux serveurs de bases de données différents.
Les produits DB2 permettent une prise en charge totale de la mise à jour multisite. Cette prise en charge concerne les applications développées à l'aide du SQL classique et les applications utilisant les produits TPM qui permettent la mise en oeuvre des spécifications de l'interface X/Open XA. Parmi ces produits figurent IBM TxSeries (CICS et Encina), MQSeries, Component Broker Series, San Francisco Project, MTS (Microsoft Transaction Server), BEA Tuxedo, NCR TopEnd, ainsi que plusieurs autres. Les conditions requises pour la configuration varient selon qu'il s'agit d'une mise à jour multisite de type SQL natif ou TPM.
Qu'ils s'exécutent en type SQL natif ou avec TPM, les programmes de mise à jour multisite doivent être précompilés avec les options CONNECT 2 SYNCPOINT TWOPHASE. Les deux types de programmes peuvent utiliser l'instruction SQL Connect pour indiquer la base de données devant être employée pour les instructions SQL suivantes. S'il n'existe pas de moniteur TP pouvant indiquer à DB2 qu'il va assurer la coordination de la transaction (comme c'est le cas lorsque DB2 reçoit les appels xa_open du moniteur TP afin d'établir la connexion à une base de données), c'est DB2 qui est utilisé pour coordonner la transaction.
Lorsque vous utilisez la mise à jour multisite avec moniteur TP, l'application doit demander les validations ou les annulations à l'aide de l'API du moniteur TP (par exemple, CICS SYNCPOINT, Encina Abort(), MTS SetAbort()).
Lorsque vous utilisez la mise à jour multisite en SQL natif, les instructions SQL COMMIT et ROLLBACK classiques doivent être utilisées.
La mise à jour multisite avec TPM permet de coordonner une transaction qui accède à des gestionnaires de ressources DB2 ou non DB2 tels qu'Oracle, Informix, SQLServer, etc. La mise à jour multisite en SQL natif est utilisée uniquement avec les serveurs DB2.
Pour qu'une mise à jour multisite fonctionne, chacune des bases de données participant à une transaction répartie doit être capable de prendre en charge une unité d'oeuvre répartie. Au moment de la rédaction de ce document, les serveurs DB2 prenant en charge les unités d'oeuvre réparties et pouvant ainsi prendre part à des transactions réparties sont les suivants :
Une transaction répartie peut effectuer des mises à jour sur toute combinaison de serveurs de bases de données, à condition qu'ils soient pris en charge. Par exemple, votre application peut, au cours d'une même transaction, mettre à jour plusieurs tables DB2 Universal Database sous Windows NT ou 2000, une base de données DB2 pour OS/390 et une base de données DB2/400.