Este apartado proporciona una visión general de la función de actualización en varias ubicaciones, tal como se aplica a los entornos que implican servidores de bases de datos de sistema principal y AS/400. Describe los productos y componentes necesarios para implantar aplicaciones de PC, UNIX y de Web que actualizan varias bases de datos de DB2 en la misma transacción.
La actualización en varias ubicaciones, también conocida como unidad de trabajo distribuida (DUOW) y confirmación en dos fases, es una función que permite a las aplicaciones actualizar datos en varios servidores de bases de datos remotos garantizando su integridad. Por ejemplo, una transacción bancaria que implica la transferencia de dinero de una cuenta a otra que se encuentre en otro servidor de bases de datos.
En una transacción de este tipo, es muy importante que las actualizaciones que impliquen operaciones de adeudo en una cuenta no se confirmen a menos que también se confirmen las actualizaciones necesarias para procesar el abono en la otra cuenta. Cuando dos servidores de bases de datos distintos gestionan los datos que representan a las mencionadas cuentas, se aplican las consideraciones de las actualizaciones en varias ubicaciones.
Los productos DB2 proporcionan un amplio soporte de las actualizaciones en varias ubicaciones. Este soporte está disponible para las aplicaciones desarrolladas utilizando SQL normal, así como para las aplicaciones que utilizan productos de supervisor de transacciones (supervisor de TP) que implantan la especificación de interfaz X/Open XA. Los ejemplos de estos productos de supervisores de TP incluyen IBM TxSeries (CICS y Encina), IBM Message and Queuing Series, IBM Component Broker Series, IBM San Francisco Project, así como Microsoft Transaction Server (MTS), BEA Tuxedo y otros varios. Existen distintos requisitos de configuración según si se utiliza la actualización en varias ubicaciones de SQL nativo o la actualización en varias ubicaciones del supervisor de TP.
Ambos programas de actualización en varias ubicaciones, el de SQL nativo y el de supervisor de TP, se deben compilar previamente con las opciones CONNECT 2 SYNCPOINT TWOPHASE. Ambos pueden utilizar la sentencia Connect de SQL para indicar qué base de datos desean que se utilice para las sentencias SQL que siguen. Si no hay ningún supervisor de TP para indicar a DB2 que va a coordinar la transacción (indicado por el hecho de que DB2 recibe las llamadas xa_open procedentes del supervisor de TP para establecer conexión con una base de datos), se utilizará el software de DB2 para coordinar la transacción.
Cuando se utiliza la actualización en varias ubicaciones del supervisor de TP, la aplicación debe solicitar una confirmación o retrotracción utilizando la API del supervisor de TP; por ejemplo, CICS SYNCPOINT, Encina Abort(), MTS SetAbort().
Cuando se utiliza la actualización en varias ubicaciones de SQL nativo, se deben utilizar las sentencias COMMIT y ROLLBACK normales de SQL.
La actualización en varias ubicaciones del supervisor de TP puede coordinar una transacción que acceda a gestores de recursos que son o no son DB2, como por ejemplo Oracle, Informix o SQLServer. La actualización en varias ubicaciones de SQL nativo sólo se utiliza con servidores DB2.
Para que una transacción de actualización en varias ubicaciones funcione, cada una de las bases de datos que participan en una transacción distribuida, debe tener la capacidad de soportar las unidades de trabajo distribuidas. En la actualidad, los servidores DB2 siguientes proporcionaban soporte de DUOW que les permitía participar en transacciones distribuidas:
Una transacción distribuida puede actualizar cualquier combinación de servidores de bases de datos soportados. Por ejemplo, la aplicación puede actualizar varias tablas en DB2 Universal Database en Windows NT o Windows 2000, una base de datos de DB2 para OS/390 y una base de datos de DB2/400, todo ello en una única transacción.
Los servidores de bases de datos de sistemas principales y AS/400 necesitan DB2 Connect para participar en una transacción distribuida que se origine en aplicaciones de PC, UNIX y de Web. Además, muchos de los entornos de actualización en varias ubicaciones que implican servidores de bases de datos de sistemas principales y AS/400 necesitan que se configure el componente Gestor de puntos de sincronismo (SPM). Cuando se crea una instancia de DB2, el DB2 SPM se configura automáticamente con los valores por omisión.
La necesidad del SPM la dicta la elección de protocolo (SNA o TCP/IP) y la
utilización de un supervisor de TP. La tabla siguiente facilita un
resumen de los entornos que requieren la utilización del SPM. Dicha
tabla muestra asimismo que se necesita DB2 Connect para cualquier acceso al
sistema principal o AS/400 desde máquinas Intel o UNIX. Además, para
las actualizaciones en varias ubicaciones se necesita el componente SPM de DB2
Connect si el acceso es a través de SNA o si se utiliza un supervisor de
TP.
¿Se utiliza Supervisor de TP? | Protocolo | ¿Se necesita SPM? | Producto requerido (elija uno) | Bases de datos de sistemas principales y AS/400 soportadas | ||
---|---|---|---|---|---|---|
Sí | TCP/IP | Sí |
|
| ||
Sí | SNA | Sí |
|
| ||
No | TCP/IP | No |
|
| ||
No | SNA | Sí |
|
|
Nota: | Una transacción distribuida puede actualizar cualquier combinación de
servidores de bases de datos soportados. Por ejemplo, la aplicación
puede actualizar varias tablas en DB2 UDB en Windows NT, una base de datos de
DB2 para OS/390 y una base de datos de DB2/400, todo ello en una única
transacción.
Para obtener más información sobre la confirmación en dos fases, así como instrucciones para configurar varios de los supervisores de TP habituales, consulte:
También puede acceder a la DB2 Product and Service Technical Library en la World Wide Web:
|