Conexiones compartibles y no compartibles
El servidor de aplicaciones da soporte a conexiones compartibles y no compartibles. Una conexión no compartible no se comparte con otros componentes de la aplicación. El componente que utiliza esta conexión tiene un control total de la conexión.
El acceso a un recurso que esté marcado como no compartible significa que hay una relación unívoca entre el manejador de conexiones que utiliza un componente y la conexión física con la que está asociada el manejador. Este acceso implica que cada llamada al método getConection devolverá un manejador de conexiones solamente para el usuario que la ha solicitado. Generalmente, deberá seleccionar el valor de no compartible si va a realizar operaciones con la conexión que pueden dar como resultado un comportamiento imprevisto en otra aplicación que esté compartiendo la conexión (por ejemplo, modificar de forma inesperada el nivel de aislamiento).
Si un recurso se marca como compartible existe una mayor posibilidad de escalado. En lugar de recuperar una conexión física nueva en cada invocación de getConnection(), la conexión física (esto es, la conexión gestionada) se comparte mediante varios manejadores de conexiones, siempre que cada solicitud getConnection tenga las mismas propiedades de conexión. No obstante, compartir una conexión significa que los usuarios no deben hacer nada con la conexión que pueda modificar su comportamiento o molestar al asociado que la comparte (por ejemplo, cambiar el nivel de aislamiento). El usuario tampoco puede codificar una aplicación en la que se supone que se comparte la conexión, ya que depende del tiempo de ejecución si se comparte o una conexión determinada.
Requisitos de propiedades de conexión
- Nombre JNDI (Java™ Naming and Directory Interface). Aunque no sea realmente una propiedad de conexión, este requisito significa simplemente que sólo puede compartir conexiones desde el mismo origen de datos en el mismo servidor.
- Autenticación de recursos
- En las bases de datos relacionales:
- Nivel de aislamiento (se corresponde con políticas de intento de acceso aplicadas a los beans CMP)
- Sólo lectura
- Catálogo
- TypeMap
Para obtener más información sobre cómo compartir una conexión con un bean CMP, consulte el tema Cómo compartir de una conexión con un bean CMP.
- Nombre JNDI. Aunque no sea realmente una propiedad de conexión, este requisito significa simplemente que sólo puede compartir conexiones desde la misma fábrica de conexiones en el mismo servidor.
- Autenticación de recursos
Las conexiones del proveedor JMS de IBM MQ no se pueden compartir porque no son de transacciones y la especificación Java™ EE Connector Architecture (JCA) sólo permite compartir los recursos de transacciones. Si res-sharing-scope se establece en shareable en una referencia de recurso JMS, el valor se ignorará y se utilizarán conexiones que no se puedan compartir. Sin embargo, las sesiones JMS para MQ son de transacciones y se pueden compartir. Las sesiones JMS se pueden compartir de forma predeterminada y el APAR PK59605 proporciona la capacidad de especificar sesiones no compartibles.
Las conexiones JMS para el proveedor de mensajería predeterminado son distintas. Con el proveedor de mensajería predeterminado, las conexiones se pueden compartir. Por otra parte, una agrupación de conexiones no gestiona las sesiones y, por lo tanto, no pueden ser compartibles o no compartibles.
Cómo compartir una conexión con un bean CMP
- Cómo compartir una conexión entre beans o métodos CMP
Cuando todos los métodos CMP utilizan el mismo intento de acceso, comparten la misma conexión física. Una política de intento de acceso diferente desencadena la ubicación de una conexión física diferente. Por ejemplo, supongamos que un bean CMP tiene dos métodos; el método 1 está asociado con el intento wsPessimisticUpdate, mientras que el método 2 tiene un intento de acceso wsOptimisticUpdate. El método 1 y el método 2 no pueden compartir la misma conexión física en una transacción. En otras palabras, es necesario que se ejecute un origen de datos XA en una transacción global.
Puede experimentar varios puntos muertos desde una base de datos si los dos métodos intentan acceder a la misma tabla. Por lo tanto, el compartimiento de una conexión viene determinado por los intentos de acceso definidos en los métodos CMP.
- Cómo compartir una conexión entre beans CMP y BMP
Recuerde que en primer lugar debe comprobar que los métodos getConnection para el bean BMP y para el bean CMP establecen las mismas propiedades de conexión. Para que el tipo de autenticación del recurso del bean CMP coincida, establezca el tipo de autenticación del recurso de bean BMP en container-managed, lo que en el descriptor de despliegue queda designado como res-auth = Container.
Adicionalmente, utilice una de las siguientes opciones para asegurarse de que se comparten las conexiones entre los tipos de beans:- Defina el mismo intento de acceso en los métodos de bean CMP y BMP. Como los dos métodos utilizan el mismo intento de acceso, comparten la misma conexión física. La ventaja de utilizar esta opción es que el programa de fondo es transparente para un bean BMP. No obstante, esta opción también hace que el BMP no se pueda portar debido a que utiliza la API ampliada de WebSphere para manejar el nivel de aislamiento. Si desea obtener más información, consulte el ejemplo de código del tema Ejemplo: Acceso a datos utilizando las API ampliadas de IBM® para compartir las conexiones entre los beans de persistencia gestionada por bean y gestionada por contenedor.
- Determine el nivel de aislamiento que utiliza el intento de acceso en un método de bean CMP y, a continuación, utilice el nivel de aislamiento correspondiente que se especifica en la referencia de recursos para buscar un origen de datos y una conexión. Esta opción es un proceso más manual, y el nivel de aislamiento puede ser distinto de una base de datos a otra. Para obtener más información, consulte la tabla de correlación de nivel de aislamiento e intentos de acceso del tema Niveles de aislamiento de intento de acceso y bloqueos de actualización y la sección Nivel de aislamiento y referencia de recurso.
- Compartimiento de una conexión entre CMP y una aplicación JDBC utilizada por un servlet o un bean de sesión Determine el nivel de aislamiento que el intento de acceso utiliza en un método de bean CMP y, a continuación, utilice el nivel de aislamiento correspondiente especificado en la referencia de recurso para buscar un origen de datos y una conexión. Para obtener más información, consulte el tema Niveles de aislamiento de intento de acceso y la sección Nivel de aislamiento y referencia de recurso.
Factores que determinan la posibilidad de compartir
La siguiente no es una lista exhaustiva. El producto puede compartir o no conexiones en distintas circunstancias.- Las conexiones adquiridas con la misma referencia de recursos (resource-ref) que
especifiquen res-sharing-scope como compartible son las únicas que se pueden
compartir. Las propiedades de referencia de recursos res-sharing-scope y res-auth, y
la propiedad isolationLevel de la extensión de IBM ayudan a determinar si es posible
compartir una conexión. La propiedad isolationLevel de la extensión de IBM se almacena en el
archivo de extensiones del descriptor de despliegue de IBM; por ejemplo,
ibm-ejb-jar-ext.xmi.
Supported configurations: Para los archivos de enlace y extensión de IBM, la extensión del nombre de archivo .xmi o .xml es diferente en función de si se utiliza una aplicación o módulo previo a Java EE 5 o una aplicación o módulo Java EE 5 o posterior. Un archivo de enlace o extensión de IBM se denomina ibm-*-ext.xmi o ibm-*-bnd.xmi donde * es el tipo de archivo de extensión o enlace como app, application, ejb-jar o web. Se aplican las condiciones siguientes:
No obstante, puede existir un módulo de Java EE 5 o posterior dentro de una aplicación que incluya archivos previos a Java EE 5 y que utilice la extensión de nombre de archivo .xmi.
Los archivos ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi, y ibm-portlet-ext.xmi siguen utilizando la extensión de archivo .xmi.
sptcfg - Solamente se pueden compartir las conexiones que se solicitan con las mismas propiedades.
- Solamente se pueden compartir las conexiones entre diferentes instancias de componentes si éstas se encuentran dentro de una transacción (la transacción iniciada por el usuario o por el contenedor).
- Solamente se puede compartir una conexión dentro del límite compartido. Los límites de compartimiento actuales son Transactions y LocalTransactionContainment (LTC).
- Reglas para compartir conexiones dentro del ámbito LTC:
- Para las conexiones compartibles, solamente se puede Volver a utilizar la conexión
dentro de una instancia de componente individual. Se puede volver a utilizar la conexión cuando se realizan las siguientes acciones: get, use,
commit/rollback, close; get, use, commit/rollback, close. Tenga en cuenta que si utiliza un control de resolución de LTC igual a
ContainerAtBoundary, entonces no es necesario start/commit ya que está acción la maneja
el contenedor.
La conexión que se devuelve la segunda vez que se ejecuta get es la misma conexión que se ha devuelto la primera vez que se ha ejecutado get, (suponiendo que se hayan utilizando las mismas propiedades). Dado que las conexiones se utilizan en serie, solamente se utiliza un manejador de conexiones con la conexión física subyacente cada vez, por lo que no existe un verdadero compartimiento de conexiones. El término "reutilización" es más correcto.
Lo que es más importante: el límite LocalTransactionContainment que incluye las dos acciones get no ha finalizado; no se ha invocado ningún método cleanUp() en el objeto ManagedConnection. Por lo tanto, la segunda acción get hereda todas las propiedades de conexión establecidas durante la primera llamada a getConnection().
- Para las conexiones compartibles, solamente se puede Volver a utilizar la conexión
dentro de una instancia de componente individual. Se puede volver a utilizar la conexión cuando se realizan las siguientes acciones: get, use,
commit/rollback, close; get, use, commit/rollback, close. Tenga en cuenta que si utiliza un control de resolución de LTC igual a
ContainerAtBoundary, entonces no es necesario start/commit ya que está acción la maneja
el contenedor.
- Las conexiones compartibles entre transacciones (ya sean transacciones
gestionadas por contenedor (CMT), transacciones gestionadas por bean (BMT) o
transacciones LTC) siguen las siguientes reglas de colocación en antememoria:
- En general, no está permitido establecer propiedades en las conexiones compartibles, ya que un manejador de conexiones no puede anticipar un cambio realizado por otro manejador de conexiones. Esta limitación forma parte de la especificación Java Platform, Enterprise Edition (Java EE).
- Los usuarios generales de adaptadores de recursos pueden establecer las
propiedades de conexión en la llamada getConnection() de la fábrica de
conexiones, pasándolas en ConnectionSpec.
Sin embargo, no se garantiza que las propiedades que se establecen en la conexión durante una transacción sean las mismas que las que se utilizan en la siguiente transacción. Como no es válido compartir conexiones fuera del ámbito de compartimiento, los manejadores de conexiones se trasladan fuera de la conexión física con la que están actualmente asociados cuando la transacción finaliza. La conexión física se devuelve a la agrupación de conexiones libres. Antes de trasladarlas a la agrupación de conexiones libres, se limpian las conexiones. La próxima vez que se utilice el manejador de conexiones, se asociará automáticamente con la conexión adecuada. Esta conexión se determinará a partir de la información de inicio de sesión de seguridad, las propiedades de conexión y (para la API de JDBC) el nivel de aislamiento especificado en la referencia de recurso ampliada, que se pasa en la solicitud original que ha devuelto el manejador actual. Una vez recuperada, se perderán las propiedades que se hayan establecido para la conexión.
- Para los usuarios de JDBC, el servidor de aplicaciones proporciona una
extensión que permite pasar las propiedades de la conexión a través de
ConnectionSpec.
Debe prestar atención cuando establezca propiedades y comparta conexiones en un ámbito de transacción local. Asegúrese de que los demás componentes con los que se está compartiendo la conexión esperen el comportamiento de sus valores.
- No puede establecer el nivel de aislamiento en una conexión compartible para la API de JDBC utilizando un adaptador de recursos relacional en una transacción global. El producto proporciona una extensión a la referencia de recursos para permitirle establecer el nivel de aislamiento. Si la aplicación requiere el uso de varios niveles de aislamiento, cree varias referencias de recursos y correlaciónelas con el mismo origen de datos o fábrica de conexiones.
Compartimiento máximo de conexiones
Para maximizar las oportunidades de compartir conexiones de una aplicación, asegúrese de que cada componente tenga el atributo Solucionador del contenedor de transacciones locales (LTC) establecido como ContainerAtBoundary. Este valor especifica que el contenedor de componentes, en lugar del código de aplicación, soluciona todas las transacciones locales del gestor de recursos (RMLT) en el ámbito de LTC. El contenedor empieza un RMLT cuando se utiliza una conexión por primera vez dentro del ámbito de LTC y la completa automáticamente al final del ámbito de LTC.
Consulte el tema, Configuración de atributos de despliegue de transacciones, para obtener instrucciones sobre cómo establecer el control de resolución de transacciones y otros atributos.
Incumplimiento del compartimiento de conexiones
- El número de manejadores de conexiones asociados con la conexión gestionada es más de uno.
- La conexión gestionada está asociada con una transacción, local o XA.
El componente y el tiempo de ejecución de J2C necesitarán detectar esta excepción de incumplimiento de compartimiento, dependiendo de cuándo y cómo se convierta la conexión gestionada en no compartible. Si la conexión gestionada se convierte en no compartible debido a una operación con el manejador de conexiones (por ejemplo, si cambia el nivel de aislamiento), el componente deberá procesar la excepción. Si la conexión gestionada se convierte en no compartible sin que lo reconozca el servidor de aplicaciones (debido a una interacción del componente con el manejador de conexiones), el adaptador de recursos puede rechazar la creación de un manejador de conexiones emitiendo la excepción de incumplimiento de compartimiento.