Agrupación De Conexiones Y Concentrador De Conexiones - IBM DB2 Connect 10.5 Guia Del Usuario

2. En el ejemplo anterior, los agentes de trabajo formarán asociaciones con los
Agrupación de conexiones y concentrador de conexiones
Aunque parezca que la agrupación de conexiones y el concentrador de conexiones
tengan similitudes, difieren en su implementación y tratan cuestiones distintas. La
agrupación de conexiones ayuda a reducir el uso de procesos de las conexiones de
la base de datos y a manejar el volumen de conexiones. El concentrador de
conexiones ayuda a aumentar la escalabilidad de la solución DB2 para z/OS y DB2
Connect optimizando la utilización de los servidores de bases de datos del sistema
principal.
154
Guía del usuario de DB2 Connect
mayoría de casos, el número de transacciones que se llevan a cabo en un
momento dado será considerablemente inferior al número de conexiones
simultáneas. El administrador del sistema podría entonces maximizar la eficacia
del sistema estableciendo los parámetros de configuración de la base de datos
de la forma siguiente:
MAX_CONNECTIONS = 4,000
MAX_COORDAGENTS = 1,000
NUM_POOLAGENTS = 1,000
El concentrador mantendrá abiertas hasta 4.000 sesiones simultáneas, aunque la
pasarela sólo gestionará 1.000 transacciones cada vez.
agentes lógicos y las interrumpirán constantemente. Estos agentes no están
desocupados y mantienen una conexión con la base de datos pero no participan
en una transacción concreta y, por tanto, están disponibles para cualquier
agente lógico (aplicación) que solicite una conexión.
El caso de las transacciones XA es algo distinto. Para este ejemplo, supongamos
que se está utilizando un Supervisor de TP con una pasarela de DB2 Connect y
una base de datos System z o IBM Power Systems. Cuando una aplicación
solicita una conexión, el concentrador activará un agente inactivo para prestar
servicio a la aplicación o creará un agente de trabajo nuevo. Supongamos que
la aplicación solicita una transacción XA. Se crea un XID para esta transacción y
el agente de trabajo se asocia al mismo.
Una vez se ha prestado servicio a la petición de la aplicación, se emite un
xa_end() y se desconecta del agente de trabajo. El agente de trabajo sigue
asociado al XID de la transacción. Ahora sólo puede prestar servicio a las
peticiones de transacciones que tenga su XID asociado.
En este momento, es posible que otra aplicación solicite una transacción que no
sea XA. Aunque no haya ningún otro agente de trabajo disponible, el agente
asociado al XID no se dejará a disposición de la segunda aplicación. Se
considera activo. Para la segunda aplicación se creará un agente de trabajo
nuevo. Cuando la segunda aplicación complete la transacción, el agente de
trabajo se liberará en la agrupación disponible.
Mientras tanto, otras aplicaciones que soliciten la transacción asociada con el
XID del primer agente podrán conectarse y al agente y desconectarse del
mismo y éste ejecutará su transacción XA dedicada por ellos. Las aplicaciones
que soliciten esta transacción en concreto se enviarán a este agente de trabajo si
está libre.
El agente de trabajo no se liberará en la agrupación general hasta que una
aplicación emita una llamada de límite de transacción (no xa_end()). Por
ejemplo, una aplicación podría finalizar la transacción con xa_commit() y
entonces el agente de trabajo descartaría su asociación con el XID y volvería a
la agrupación disponible. En este momento, cualquier aplicación solicitante
podría utilizarlo para otra transacción XA o para una transacción que no sea
XA.