Manejadores de conexiones

Un manejador de conexiones es una representación de una conexión física. Para utilizar un recurso de fondo, por ejemplo una base de datos relacional en WebSphere Application Server, debe obtener una conexión con ese recurso. Cuando llama al método getConnection(), se devuelve un manejador de conexiones. El manejador no es la conexión física. La conexión física la gestiona el gestor de conexiones.

Hay dos configuraciones significativas que influyen en la utilización y el comportamiento de los manejadores de conexiones. El primero es res-sharing-scope, que está definido por la referencia de recurso utilizada para buscar el origen de datos o la fábrica de conexiones. Esta propiedad indica al gestor de conexiones si se puede compartir o no esta conexión.

El segundo factor que influye en el comportamiento del manejador de conexiones es el patrón de uso. Hay básicamente dos patrones de uso. El primero se llama el patrón obtener/utilizar/cerrar. Se utiliza dentro de un solo método y sin llamar a otro método que pueda obtener una conexión del mismo origen de datos o la misma fábrica de conexiones. Una aplicación que utilice este patrón realiza las siguientes acciones:
  1. obtiene una conexión
  2. efectúa sus operaciones
  3. compromete (si resulta adecuado)
  4. cierra la conexión.
El segundo patrón de uso se llama el patrón de manejador en memoria caché. Aquí es donde la aplicación:
  1. obtiene una conexión
  2. empieza una transacción global
  3. trabaja en la conexión
  4. compromete una transacción global
  5. vuelve a trabajar en la conexión
Un manejador en memoria caché es un manejador de conexiones que la aplicación mantiene a través de los límites de métodos y transacciones. Tenga en cuenta las siguientes consideraciones cuando utilice manejadores en memoria caché:
  • El soporte del manejador en memoria caché requiere gestión adicional de manejadores de conexiones a través de estos límites, lo que puede afectar al rendimiento. Por ejemplo, en una aplicación JDBC, las sentencias Statements, PreparedStatements y ResultSets se cierran implícitamente cuando finaliza la transacción, pero la conexión continúa siendo válida.
  • Se recomienda no almacenar la conexión en la memoria caché más allá del límite de la transacción para las conexiones compartibles. Es preferible el patrón get/use/close.
  • La memoria caché de los manejadores de conexiones en los métodos de servlet está limitada a los recursos JDBC y JMS (Java™ Message Service). Los demás recursos no relacionados como, por ejemplo, los objetos (CICS) o IMS (Customer Information Control System), no pueden tener actualmente sus manejadores de conexiones almacenados en la memoria caché en un servlet. Debe obtener, utilizar y cerrar el manejador de conexiones dentro de cada invocación de método. (Esta limitación sólo se aplica a servlets de una hebra, ya que los servlets de varias hebras no permiten la colocación en memoria caché de manejadores de conexiones).
  • No puede pasar un manejador de conexiones en memoria caché de una instancia de un cliente de acceso a datos a otra instancia de cliente. La transferencia entre instancias de cliente puede supone la posibilidad de que una instancia utilice un manejador de conexiones al que se hace referencia en otra. Esta relación sólo puede dar problemas, ya que el código de gestión del manejador de conexiones procesa las tareas de cada instancia de cliente por separado. Por lo tanto, las transferencias de manejadores de conexiones dan lugar a escenarios de tiempo de ejecución en los que se desencadenan excepciones. Por ejemplo:
    1. El código de aplicación de una instancia de cliente que recibe un manejador transferido cierra el manejador.
    2. Si la instancia de cliente que mantiene la referencia original al manejador intenta reclamarlo, el servidor de aplicaciones emite una excepción.

El siguiente segmento de código muestra el patrón de conexión en memoria caché.

Connection conn = ds.getConnection();
ut.begin();
conn.prepareStatement("....."); // La conexión se ejecuta en modalidad de transacción global
...
ut.commit();
conn.prepareStatement("....."); // La conexión continúa siendo válida pero se ejecuta en autoCommit(True);
...

Conexiones no compartibles

En los siguientes apartados se describen algunas de las características de los manejadores de conexiones recuperados con un res-sharing-scope igual a no compartible.
  • Posibles ventajas de conexiones no compartidas
    • La aplicación siempre mantiene un enlace directo con una conexión física (conexión gestionada).
    • La conexión siempre dispone de una relación unívoca entre el manejador de conexiones y la conexión gestionada.
    • En la mayoría de los casos, la conexión no se cierra hasta que la cierra la aplicación.
    • Puede utilizar un manejador de conexiones no compartido en memoria caché en varias transacciones.
    • La conexión puede tener ventajas de rendimiento en algunas situaciones del manejador en memoria caché. Dado que las conexiones no compartidas no disponen de la carga adicional de tener que poner en marcha los manejadores de conexiones de las conexiones gestionadas al final de la transacción, hay menos carga adicional al utilizar conexiones no compartidas en memoria caché.
  • Posibles inconvenientes de conexiones no compartidas
    • Uso ineficaz de los recursos de conexiones. Por ejemplo, si dentro de una sola transacción obtiene más de una conexión (con las mismas propiedades) con el mismo origen de datos o fábrica de conexiones (la misma ref-recurso), utilice varias conexiones físicas cuando utilice conexiones no compartibles.
    • Conexiones desaprovechadas. Es importante no dejar abierto el manejador de conexiones (la aplicación no llama al método close()) más de lo necesario. Cuando está abierta una conexión no compartible, la conexión física no está disponible para ningún otro componente, aunque la aplicación no esté utilizando actualmente esa conexión. A diferencia de una conexión compartible, una conexión no compartible no se cierra al final de una transacción o una llamada de servlet.
    • Consideraciones sobre puntos muertos. En función de cómo interactúan los componentes con la base de datos en una transacción, el uso de conexiones no compartidas puede originar un punto muerto en la base de datos. Por ejemplo, dentro de una transacción, el componente A obtiene una conexión con el origen de datos X y actualiza la tabla 1 y a continuación llama al componente B. El componente B obtiene una conexión con el origen de datos X y actualiza/lee la tabla 1 (o aún peor la misma fila que el componente A). En algunas circunstancias, dependiendo de la base de datos específica, su esquema de bloqueo y el nivel de aislamiento de la transacción, podría producirse un punto muerto.

      En el mismo ejemplo, pero con una conexión compartida, no se produce un punto muerto porque todo el trabajo se hace en la misma conexión. Hay que tener en cuenta que cuando se escribe un código que utiliza conexiones compartidas, se utiliza una estrategia que requiere que se ejecuten varios elementos de trabajo en la misma conexión, posiblemente dentro de la misma transacción. Si decide utilizar una conexión compartida, deberá establecer correctamente la propiedad Número máximo de conexiones en la fábrica de conexiones o el origen de datos. Si sobrepasa el número máximo de conexiones y no se cierran las conexiones no compartibles antes del final del tiempo de espera de la conexión, se producirá una excepción para las solicitudes de conexión en espera.

Conexiones compartibles

En los siguientes apartados se describen algunas de las características de los manejadores de conexiones recuperados con un valor de res-sharing-scope igual a compartible.
  • Posibles ventajas de conexiones compartidas
    • Dentro de una instancia de compartimiento de conexiones, los componentes de aplicación pueden compartir una conexión gestionada con uno o más manejadores de conexiones, en función de cómo se haya recuperado el manejador y de las propiedades de conexión que se estén utilizando.
    • Pueden hacer un uso más eficaz de los recursos. Las conexiones compartibles no son válidas fuera de su límite de compartimiento. Por esta razón, al final de un límite de compartimiento (por ejemplo, de una transacción), el manejador de conexiones ya no estará asociado a la conexión gestionada que estaba utilizando dentro del límite de compartimiento (esto sólo se aplica cuando se utiliza un patrón de manejador en memoria caché). Se devolverá la conexión gestionada a la agrupación de conexiones libres para reutilización. Los recursos de conexión ya no se retienen después del final del ámbito de compartimiento actual.

      Si se utiliza el patrón de manejador en memoria caché, la próxima vez que se utilice el manejador dentro de un nuevo ámbito de compartimiento, el tiempo de ejecución del servidor de aplicaciones garantiza que el manejador se volverá a asociar a una conexión gestionada que sea adecuada para el ámbito de compartimiento actual y que tenga las mismas propiedades con las que se había recuperado inicialmente el manejador. No se recomienda cambiar las propiedades en conexiones compartibles. Si se modifican, otros componentes que comparten la misma conexión podrían no funcionar según lo esperado. Además, cuando se utilizan manejadores en memoria caché, el valor de la propiedad modificada no se recordará en los ámbitos de compartimiento.

  • Posibles inconvenientes de conexiones compartidas
    • No siempre está soportado el compartimiento dentro de un solo componente (por ejemplo, un enterprise bean y sus objetos Java relacionados). La especificación actual ofrece a los adaptadores de recursos la posibilidad de sólo permitir un manejador de conexiones activo a la vez.
      Si un adaptador de recursos opta por implementar esta opción, entonces el siguiente caso ocasionará una excepción de manejador no válido: un componente que utiliza conexiones compartibles obtiene una conexión y la utiliza. Sin cerrar la conexión, el componente llama a una clase de programa de utilidad (objeto Java) que obtiene un manejador de conexiones con la misma conexión gestionada y lo utiliza. Dado que el adaptador de recursos sólo da soporte a un manejador activo a la vez, el primer manejador de conexiones ya no es válido. Si se devuelve el control al objeto del programa de utilidad sin cerrar su manejador, el primer manejador no es válido y desencadena una excepción cada vez que se intenta utilizar.
      Nota: Esta excepción sólo se produce cuando se llama a un objeto de programa de utilidad (un objeto Java).

      No todos los adaptadores de recursos tienen esta limitación; sólo se produce en determinadas implementaciones. El Adaptador de recursos relacional (RRA) de WebSphere no tiene esta limitación. Los orígenes de datos que se utilicen con el RRA no tendrán esta limitación. Si tiene un adaptador de recursos con esta limitación, puede solucionarlo serializando el acceso a la conexión gestionada. Si cierra siempre el manejador de conexiones antes de obtener otro (o cierra el manejador antes de llamar al código que obtiene el otro manejador), y antes de volver de un método, podrá tener dos piezas de código compartiendo la misma conexión gestionada. Lo único que no puede es utilizar la conexión para los dos sucesos al mismo tiempo.

    • Si intenta cambiar el nivel de aislamiento de una conexión compartible basada en JDBC en una transacción global, se producirá una excepción. La forma correcta de obtener conexiones con niveles de aislamiento de transacción diferentes es configurando la referencia de recurso ampliada de IBM®.
    • NO está soportado que una aplicación cierre los manejadores de conexiones en conexiones compartibles, y se producirán errores. Sin embargo, puede evitar esta limitación si utiliza el Adaptador de recursos relacional.

Optimización de asociaciones de conexiones poco activas

El gestor de conexiones Java Platform, Enterprise Edition (Java EE) Connector (J2C) implementó el soporte de manejador inteligente. Esta tecnología permite asignar un manejador de conexiones a una aplicación cuando la conexión gestionada asociada con ese manejador de conexiones está siendo utilizada por otras aplicaciones (siempre que la aplicación original no esté utilizando la conexión). Este concepto forma parte de la especificación JCA (Java EE Connector Architecture) 1.5. (Puede encontrarlo en el documento de la especificación JCA 1.5, en el apartado denominado "Lazy Connection Association Optimization (Optimización de asociaciones de conexiones poco activas)"). El soporte de manejador inteligente añade el uso de un método en el objeto ConnectionManager, el método LazyAssociatableConnectionManager(), y una nueva interfaz de marcador, la clase DissociatableManagedConnection. Debe configurar el proveedor del adaptador de recursos para que esta funcionalidad esté disponible en su entorno. (En el caso de RRA, WebSphere Application Server es el proveedor). En el fragmento de código siguiente se muestra cómo incluir el soporte de manejador inteligente:
package javax.resource.spi;
import javax.resource.ResourceException;

interface LazyAssociatableConnectionManager { // application server
    void associateConnection(
        Object connection, ManagedConnectionFactory mcf,
        ConnectionRequestInfo info) throws ResourceException;
}

interface DissociatableManagedConnection { // resource adapter
    void dissociateConnections() throws ResourceException;
}

Esta interfaz DissociatableManagedConnection añade otro estado al objeto Connection: inactivo. Ahora, una conexión puede estar activa, cerrada e inactiva. El objeto de conexión entra en el estado inactivo cuando se borra el objeto ManagedConnection correspondiente. La conexión permanece inactiva hasta que un componente de aplicación intenta reutilizarla. A continuación, el adaptador de recursos vuelve a llamar al gestor de conexiones para reasociar la conexión con un objeto ManagedConnection activo.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cdat_cconpconh
File name: cdat_cconpconh.html