Share via


Consideraciones sobre el rendimiento de la confirmación en dos fases

Cuando un componente integrador de transacciones (TI) se ejecuta dentro de una transacción, el entorno en tiempo de ejecución de TI envía un mensaje al Coordinador de transacciones distribuidas de Microsoft (DTC) en el entorno com+, enlistándose en la transacción como un tipo especial de administrador de recursos de LU 6.2. Una vez que TI envía su búfer de datos al host y recibe la respuesta, llama al método y devuelve el SetComplete 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 administradores de recursos, incluido el entorno en tiempo de ejecución de TI. TI genera el Prepare PS Header definido en formatos de SNA y lo envía al host. Recibe un RequestCommit en respuesta, que indica que las actualizaciones del host son válidas y se pueden confirmar, y pasa esta información de nuevo a DTC. DTC recopila los votos de todos los administradores de recursos y, si todos están preparados de acuerdo, fuerza a escribir un registro de confirmación en el registro y envía el Committed mensaje. De nuevo, TI lo traduce en , SNA PS Headerrecibe la respuesta y lo traduce de nuevo a DTC. Si todo funciona según lo previsto, DTC revierte la transacción y la conversación appC/LU 6.2 se desasigna.

Nota

Ni TI ni el AP deben preocuparse por un verbo APPC o CPI/C SYNCPT. El creador de transacciones toma la decisión de "tomar un SyncPoint", se expresa en la semántica de las transacciones OLE e implica a todos los participantes de 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 para 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 agrega 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 inscribirse, 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 (TP) asociado 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á administrando la transacción de forma remota para el host, y incurriría en la sobrecarga de crear una nueva transacción, inscribirla y realizar los intercambios 2PC con el host, pero el método de TI sería una transacción a 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 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.

Consulte también

Guía de rendimiento del Integrador de transacciones