Ajuste de las agrupaciones de conexiones
Utilización de las agrupaciones de conexiones para aliviar la actividad general de la gestión de conexiones y disminuir las tareas de desarrollo para el acceso de datos. Cada vez que una aplicación intenta acceder a un almacén de programa de fondo (por ejemplo, una base de datos), necesita recursos para crear, mantener y liberar una conexión en ese almacén de datos. Para reducir el trabajo que añade este proceso a los recursos de aplicación generales, el servidor de aplicaciones permite a los administradores establecer una agrupación de conexiones de programa de fondo en un servidor de aplicaciones que las aplicaciones pueden compartir. La agrupación de conexiones distribuye la carga de la conexión entre varias peticiones de usuarios, con lo que se conservan los recursos de aplicación para futuras peticiones.
Acerca de esta tarea

Procedimiento
- Impida un punto muerto de conexiones. Puede producirse un punto muerto si la aplicación requiere más de una conexión simultánea por hebra, y si la agrupación de conexiones de la base de datos no es suficientemente grande para el número de hebras. Suponga que cada una de las hebras de aplicación requiere dos conexiones simultáneas de base de datos y el número de hebras es igual al tamaño máximo de la agrupación de conexiones. El punto muerto puede producirse cuando se cumplen las dos condiciones siguientes:
- Todas las hebras tienen su primera conexión a la base de datos y todas están en uso, y
- Todas las hebras están esperando una segunda conexión de la base de datos, y ninguna estaría disponible porque todas las hebras están bloqueadas.
Para impedir el punto muerto en este caso, aumente el valor de número máximo de conexiones de la agrupación de conexiones de la base de datos al menos en una unidad. Esto garantiza que al menos una de las hebras en espera obtenga la segunda conexión a la base de datos, y evita que se provoque una situación de punto muerto.
Para prevenir de forma general el punto muerto de la conexión, codifique las aplicaciones para utilizar sólo una conexión por hebra. Si codifica la aplicación de forma que precise de C conexiones de bases de datos simultáneas por hebra, la agrupación de conexiones debe tener soporte para al menos el número de conexiones siguiente, donde T es el número máximo de hebras:T * (C - 1) + 1
Los valores de la agrupación de conexiones están directamente relacionados con el soporte del número de conexiones que ha especificado en la configuración del servidor de bases de datos. Si aumenta el número máximo de conexiones en la agrupación y los valores correspondientes de la base de datos no se aumentan de acuerdo a ello, la aplicación podría fallar. Los errores de excepción SQL resultantes se mostrarán en las ubicaciones siguientes:Una de las causas más comunes de punto muerto de conexión es el uso de la misma agrupación de conexiones por parte de los servlets y Enterprise JavaBeans (EJB), y si el servlet invoca directa o indirectamente el bean. Por ejemplo, un servlet que obtiene una conexión JMS de la agrupación de conexiones, envía un mensaje al bean controlado por mensajes (MDB) y espera una respuesta. El MDB se ha configurado para utilizar la misma agrupación de conexiones que el servlet, por lo tanto, se necesita otra conexión de la agrupación para que el MDB envíe una respuesta al servlet. Los servlets y enterprise beans no comparten la misma agrupación de conexiones. Éste es un ejemplo clásico de hebras simultáneas (C), donde C=2 y T es el tamaño máximo de las agrupaciones de hebras de servlet y EJB.el archivo stderr.log
SYSOUT del sirviente
- Inhabilite la agrupación de conexiones.
- Para los adaptadores de recursos relacionales (RRAs), añada la propiedad
personalizada disableWASConnectionPooling para los orígenes de
datos.
- Pulse JDBC > Orígenes de datos.
- Pulse en el nombre del origen de datos que desea configurar.
- Pulse Propiedades personalizadas bajo la cabecera Propiedades adicionales.
- Pulse Nuevo.
- Complete los campos necesarios con la siguiente información:
- Nombre: disableWASConnectionPooling
- Valor: true
- Para otros adaptadores de recursos, consulte las especificaciones de enlace
correspondientes al adaptador de recursos a fin de configurar las aplicaciones para
inhabilitar la agrupación de conexiones.
- Inhabilite de forma programática la agrupación de conexiones mediante el adaptador de recursos.
- El servidor de aplicaciones refuerza el siguiente código para detectar la excepción
javax.resource.NotSupportedException e inhabilitar la agrupación de conexiones:
_managedFactory.matchManagedConnections(s,subject,cri); // 169059 174269 } catch(javax.resource.NotSupportedException e){
- Para los adaptadores de recursos relacionales (RRAs), añada la propiedad
personalizada disableWASConnectionPooling para los orígenes de
datos.
- Habilite la inclusión diferida.
En el entorno del servidor de aplicaciones, inclusión diferida hace referencia a la técnica por la que el servidor de aplicaciones espera hasta que la conexión se utiliza antes de que la conexión se incluya en el ámbito de la unidad de trabajo (UOW) de la aplicación.
Observe la ilustración siguiente de inclusiones diferidas:- Un componente de aplicación que utiliza las inclusiones diferidas invoca el método getConnection desde una transacción global.
- El componente de aplicación no utiliza de modo inmediato la conexión.
- Cuando la aplicación emita la llamada de uso inicial de la conexión, el gestor de transacciones intercepta la llamada.
- El gestor de transacciones incluye el recurso XA para la conexión e invoca el método XAResource.start.
- El gestor de conexiones asociado al recurso XA envía la llamada a la base de datos.
La inclusión diferida permite un mayor rendimiento en el caso de que se obtenga una conexión, pero no se utilice, en el ámbito de UOW. Este método evita el coste que supone la participación de la transacción hasta el UOW en que se produzca la participación.
Consulte al proveedor del adaptador de recursos si necesita saber si el adaptador de recursos proporciona esta función. El adaptador de recursos relacional del servidor de aplicaciones da soporte automáticamente a la inclusión diferida.
Incorporación de la inclusión diferida en el código:
La especificación Java™ Platform, Enterprise Edition (Java EE) Connector Architecture (JCA) versión 1.5 y posteriores llama a la optimización de inclusión de transacciones poco activas de la técnica de inclusión diferida. Este soporte se proporciona mediante una interfaz de marcador (LazyEnlistableManagedConnection) y un método en el gestor de conexiones (LazyEnlistableConnectionManager()):package javax.resource.spi; import javax.resource.ResourceException; import javax.transaction.xa.Xid; interface LazyEnlistableConnectionManager { // application server void lazyEnlist(ManagedConnection) throws ResourceException; } interface LazyEnlistableManagedConnection { // resource adapter }
- Controle la compartición de la agrupación de conexiones. Puede utilizar la propiedad personalizada de agrupación de conexiones defaultConnectionTypeOverride, o globalConnectionTypeOverride, para que un origen de datos o fábrica de conexiones determinada controle la compartición de conexiones:
- La propiedad defaultConnectionTypeOverride cambia el valor de compartimiento predeterminado de una agrupación de conexiones. Esta propiedad permite controlar el compartimiento de conexiones para consultas directas. Si se configuran referencias de recursos para este origen de datos o esta fábrica de conexiones, las configuraciones de referencias de recursos tienen prioridad sobre los valores de la propiedad defaultConnectionTypeOverride. Por ejemplo, si una aplicación está efectuando consultas directas y se necesitan conexiones no compartidas, establezca la propiedad defaultConnectionTypeOverride en unshared.
- El valor especificado para la propiedad personalizada globalConnectionTypeOverride tiene prioridad sobre todos los otros valores de compartimiento de conexiones. Por ejemplo, si establece esta propiedad en no compartir, todas las solicitudes de conexión son no compartidas para consultas directas y búsquedas de referencia de recursos. Esta propiedad le proporciona una forma rápida de probar las consecuencias de mover todas las conexiones de una fábrica de orígenes de datos o de conexiones al valor no compartir o compartir, sin cambiar ningún valor de las referencias de recursos.
Si especifica valores para las propiedades defaultConnectionTypeOverride y globalConnectionTypeOverride, sólo se utilizan los valores especificados para la propiedad globalConnectionTypeOverride para determinar el tipo de compartición de conexión.
Para añadir estas nuevas propiedades personalizadas a los valores de un origen de datos o de una agrupación de conexiones de la fábrica de conexiones, debe crearse una nueva propiedad personalizada de la agrupación de conexiones. Para añadir una de estas propiedades a un origen de datos, utilice la consola de administración. Pulse Recursos > JDBC > Orígenes de datos. Seleccione el origen de datos de la lista y pulse Propiedades adicionales > Propiedades de la agrupación de conexiones > Propiedades personalizadas de la agrupación de conexiones > Nuevo. Para otras fábricas de conexiones J2C o JMS, vaya hasta la definición de la fábrica de conexiones de la consola administrativa. A continuación, seleccione Propiedades adicionales > Agrupación de conexiones > Propiedades personalizadas de agrupación de conexiones > Nuevo. Ahora especifique defaultConnectionTypeOverride oglobalConnectionTypeOverride en el campo Nombre y shared ounshared en el campo Valor.Importante: Las propiedades se deben establecer en Propiedades personalizadas de la agrupación de conexiones y NO en Propiedades personalizadas generales del origen de datos o la fábrica de conexiones. Realizar automáticamente una acción de mitigación si una agrupación de conexiones no se puede establecer una conexión con su gestor de recursos configurado.
Al utilizar las propiedades failureNotificationActionCode y failureThreshold, una agrupación de conexiones puede configurarse de modo que, cuando una fábrica de conexiones no pueda establecer una conexión con su gestor de recursos configurado, el tiempo de ejecución de WebSphere Application Server for z/OS lleve a cabo una acción de mitigación autónoma, para minimizar el impacto que la anomalía pueda provocar en el usuario final. Cuando una fábrica de conexiones es capaz de volver a establecer una conexión en el gestor de recursos configurado, la acción de mitigación autónoma se invierte. Un ejemplo de este tipo de acción de mitigación es que el tiempo de ejecución puede emitir un comando de "pausa de escuchas" para el servidor con el recurso anómalo, lo que impide que el servidor acepte un nuevo trabajo. Cuando se combina con un extremo frontal de alta disponibilidad, el trabajo nuevo se puede direccionar a otros servidores de un clúster.
Cuando una fábrica de conexiones o un origen de datos determinados alcanzan un valor de umbral de anomalía predeterminado o especificado, se envía una notificación al tiempo de ejecución de z/OS. La notificación de anomalía incluye un código de acción configurado que determina el modo en que el entorno de ejecución responde a la notificación de anomalía. Consulte el tema Propiedades personalizadas de la agrupación de conexiones para ver las definiciones de código de acción.
Para utilizar estas propiedades, debe definirlas como nuevas propiedades personalizadas de la agrupación de conexiones. Esto se puede hacer mediante la consola administrativa de la forma siguiente: pulse Proveedores JDBC > Orígenes de datos > Agrupaciones de conexiones > Propiedades personalizadas > Nuevo. A continuación, especifique failureNotificationActionCode o failureNotification en el campo Nombre y el valor adecuado en el campo Valor.
Para aprender más cosas sobre los valores de estas propiedades personalizadas, consulte el tema, Propiedades personalizadas de la agrupación de conexiones.
- Descartar conexiones.
Los valores de tiempo de recopilación y de tiempo de espera no utilizado no hacen que las conexiones desocupadas o no utilizadas se descarten, si la región de servant está desocupado. Esta situación podría provocar que algunas conexiones de DB2 se retengan más tiempo del necesario.
Si prefiere que las conexiones de descarten a la hora especificada por una combinación de valores de tiempo de recopilación y tiempo de espera no utilizado, aunque esta preferencia pueda provocar que una región de servant inactiva vuelva a activarse, puede añadir la propiedad personalizada nondeferredreaper a los valores del origen de datos del proveedor del controlador JDBC. Cuando añade esta propiedad personalizada, las conexiones se descartan a la hora especificada por una combinación de valores de tiempo de recopilación y de tiempo de espera no utilizado.
Para añadir esta propiedad personalizada a los valores del origen de datos del proveedor del controlador JDBC, en la consola de administración, pulse Recursos > Proveedores JDBC > Proveedor del controlador JDBC de DB2 Universal > Orígenes de datos > origen_datos > Propiedades personalizadas > Nueva. A continuación, especifique nondeferredreaper en el campo Nombre, true en el campo Valor y java.lang.Boolean en el campo Tipo. Este nuevo valor no entra en vigor hasta que reinicie el servidor que está utilizando este origen de datos.
Avoid trouble: Activar una región de servant desocupada con el único objetivo de descartar una conexión no utilizada podría causar un uso de la CPU adicional y, a veces, no se deseado. Asimismo, es posible que se deban registrar e ignorar los siguientes mensajes de aviso:
gotchaDSRA8200W: Configuración de DataSource: DSRA8020E: Aviso: La propiedad 'nondeferredreaper' no existe en el DataSource classcom.ibm.db2.jcc.DB2ConnectionPoolDataSource.
- Depuración de agrupaciones de conexiones basada en la política de depuración.
Cuando el modelo de detección de errores de la agrupación de conexiones se configura para la correlación de excepciones, la excepción de conexión en punto muerto indica que la conexión ya no es válida.
Normalmente, cuando se genera una StaleConnectionException a partir del proceso de correlación de excepciones, se dispara un suceso de error de conexión y, posteriormente, la agrupación de conexiones se depura. No obstante, en este caso, SCE se instancía, el código existente no tiene la funcionalidad de disparar el suceso de error de conexión y la agrupación no se depura. Cuando las conexiones terminan por parte de la base de datos al solicitar una conexión nueva, el controlador lanza una XAException. Si se genera errorDetectionModel=ExceptionMapping, se disparará un ConnectionErrorEvent de forma que la agrupación de conexiones se depure en la política de depuración.
Para añadir esta propiedad personalizada a los valores del origen de datos del proveedor del controlador JDBC, en la consola de administración, pulse Recursos > Proveedores JDBC > Proveedor del controlador JDBC de DB2 Universal > Orígenes de datos > origen_datos > Propiedades personalizadas > Nueva. A continuación, especifique fireCEEventOnSCE en el campo Nombre, true en el campo Valor y java.lang.Boolean en el campo Tipo. Este nuevo valor no entra en vigor hasta que reinicie el servidor que está utilizando este origen de datos.
El código RRA de WebSphere RRA se ha cambiado de forma que la agrupación se depure de forma apropiada cuando se produzca una StaleConnectionException al utilizar ExceptionMapping como modelo de errorDetection.
Subtopics


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tdat_conpoolman
File name: tdat_conpoolman.html