Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Cuando un componente Integrador de Transacciones (TI) se ejecuta dentro de una transacción, el entorno de ejecución en tiempo de ejecución de TI envía un mensaje al Coordinador de Transacciones Distribuidas (DTC) de Microsoft en el entorno COM+, registrándose en la transacción como un tipo especial de gestor de recursos LU 6.2. Una vez que TI envía su búfer de datos al host y recibe la respuesta, llama al SetComplete método y devuelve el control a COM+. En este momento, la aplicación cliente u otro componente que conduce TI, también puede realizar otro trabajo incluido en la misma transacción. Cuando todos los administradores de recursos han realizado sus actualizaciones y emitido SetComplete, el creador de la transacción (que puede ser COM+ para una transacción automática) envía el Commit método a DTC. DTC envía el mensaje de primera fase (Prepare) a todos los gestores de recursos, incluido el entorno de ejecución de TI. TI genera el Prepare PS Header definido en formatos SNA y lo envía al host. Recibe en respuesta un RequestCommit, que indica que las actualizaciones del host son válidas y se pueden confirmar, y devuelve esta información al DTC. DTC recopila los votos de todos los administradores de recursos y, si todos están preparados, fuerza la escritura de un registro de confirmación en el registro y envía el mensaje Committed. De nuevo, TI lo convierte en SNA PS Header, recibe la respuesta y lo traduce de nuevo a DTC. Si todo funciona según lo planeado, DTC revierte la transacción y la conversación APPC/LU 6.2 se desasigna.
Nota:
Ni TI ni el AP necesitan preocuparse por un verbo APPC o CPI/C SYNCPT. La decisión de "tomar un SyncPoint" es tomada por el creador de transacciones, se expresa en la semántica de las transacciones OLE, e implica a todos los participantes en la transacción, no solo las ramas de TI LU 6.2. El rol de TI está en un nivel inferior; TI actúa como administrador de recursos en DTC. Se traduce entre las interfaces COM usadas por DTC y los protocolos SNA comprendidos por el host, para realizar las dos fases del protocolo y permitir que DTC tome la decisión de confirmación entre la fase uno y la segunda.
Desde el punto de vista del rendimiento, garantizar la atomicidad de las actualizaciones del host implica una sobrecarga significativa e inevitable. Hay dos flujos de mensajes de ida y vuelta adicionales al host para la confirmación en dos fases (2PC), además de los flujos de mensajes de Windows para inscribir y el registro de transacciones (escrituras de disco forzado) por DTC y en el host. Las transacciones que no requieren una gran cantidad de procesamiento de lógica de negocios pueden tardar dos veces o más en completarse cuando se compara con la misma transacción sin 2PC.
La única vez que debe configurar un componente de TI para admitir transacciones ACID es cuando el programa de transacciones host asociado (TP) modifica un recurso crítico que debe mantenerse coherente con los recursos en el sistema operativo Windows. Si el TP no modificará ningún recurso para el que se debe garantizar la coherencia, configure el componente de TI como No admite transacciones, de modo que no se intente 2PC. A continuación, también puede usar el protocolo TCP/IP. El protocolo TCP/IP no admite 2PC.
Los componentes de TI nunca deben configurarse como Requiere una nueva transacción. Esto significa que está gestionando la transacción de forma remota para el host, lo que implicaría la sobrecarga de crear una nueva transacción, enlistarla y llevar a cabo los intercambios de 2PC con el host, pero el método TI sería una transacción por sí misma. Es más eficaz permitir que CICS e IMS administren sus propias transacciones. Las actualizaciones del sistema operativo Windows no formarían parte de esa transacción, por lo que se confirmarían o revertirían de forma independiente.
Nota:
El procesamiento de lógica de negocios adicional en el mismo servidor reduce los límites de rendimiento, robando parte de la CPU. Sin embargo, el costo puede ser relativamente pequeño en el ámbito del presupuesto general del tiempo de respuesta.