Contenedor de transacciones locales
IBM® WebSphere Application Server da soporte a LTC (Local Transaction Containment), que puede configurar utilizando los descriptores de despliegue ampliados de transacción local. El soporte de LTC proporciona determinadas ventajas para los programadores de aplicaciones. Utilice los escenarios que se proporcionan y la lista de puntos a tener en cuenta, para ayudarle a decidir la mejor forma de configurar el soporte para las transacciones locales.
En los apartados siguientes se describen las ventajas que ofrece el soporte LTC y cómo establecer los descriptores de despliegue ampliados de transacciones locales en cada situación.
- Puede desarrollar un enterprise bean o servlet que acceda a una o más bases de datos que son independientes y no necesitan coordinación.
- Si un enterprise bean no necesita utilizar transacciones globales, a menudo
es más eficaz desplegar el bean con el descriptor de despliegue para el tipo de
transacción de contenedores en NotSupported en vez de Required.
Con el soporte de transacción local ampliado del servidor de aplicaciones, las aplicaciones pueden realizar la misma lógica empresarial en un contexto de transacción no específico que podrían hacer en una transacción global. Un enterprise bean, por ejemplo, se ejecuta bajo un contexto de transacción no especificado si se despliega con un tipo de transacción de contenedor de No soportado o Nunca.
El soporte de transacción local ampliado proporciona un límite de transacción local implícito, gestionado por contenedor, dentro del cual el contenedor compromete las actualizaciones de aplicación y limpia las conexiones. Puede diseñar aplicaciones con más independencia de las cuestiones de despliegue. Así se hace uso de un tipo de transacción de contenedor de Soporta mucho más sencillo, por ejemplo, cuando se puede llamar a la lógica empresarial con o sin contexto de transacción global.
Una aplicación puede seguir un patrón obtener-utilizar-cerrar (get-use-close) de uso de conexión independientemente de si la aplicación se ejecuta en una transacción. La aplicación puede depender de que la acción de cierre se comporte de la misma forma en todas las situaciones, esto es, dicha acción no hace que se produzca un retrotraimiento de la conexión si no hay una transacción global.
Hay muchos escenarios en los que la coordinación ACID de gestores de recursos múltiples no es necesaria. En dichos escenarios, la ejecución de la lógica empresarial en una política Transacción de NotSupported (Sin soporte) funciona mejor que en una política Required (Necesario). Esta ventaja se aplica mediante el establecimiento del descriptor de despliegue, en la sección Transacciones locales, del atributo Resolver en ContainerAtBoundary. Con este valor, las interacciones de aplicaciones con proveedores de recursos ,como bases de datos, se gestionan dentro de transacciones locales de gestor de recursos (RMLT) implícitas que el contenedor inicia y detiene. El contenedor compromete las RMLT en el límite de contención que se especifica mediante el atributo Límites de la sección Transacciones locales; por ejemplo al final de un método. Si la aplicación devuelve el control al contenedor debido a una excepción, el contenedor retrotrae las RMLT que haya arrancado.
Este uso se aplica tanto a los servlets como a los enterprise beans.
- Puede utilizar transacciones locales en un entorno gestionado que garantiza la limpieza.
- Las aplicaciones que quieren controlar las RMLT, para arrancarlas y pararlas de forma
explícita, pueden utilizar el valor predeterminado de Aplicación para el descriptor
de despliegue ampliado Resolver en la sección Transacciones locales. En esta situación, el
contenedor asegura la limpieza de la conexión en el límite del contexto de transacción
local.
Las especificaciones de las aplicaciones de empresa de la plataforma Java™ que describen el uso de aplicaciones de transacciones locales lo hacen de la forma proporcionada por los valores predeterminados de Aplicación para el descriptor de despliegue ampliado Resolver y Retrotracción para el descriptor de despliegue ampliado de Acción no resuelta, en la sección Transacciones locales. Cuando el descriptor de Extended Deployment Acción no resuelta de la sección Transacciones locales se establece en Commit (Comprometer), el contenedor compromete cualquier RMLT iniciada por la aplicación pero que no se completa cuando finaliza la contención de transacción local (por ejemplo, cuando finaliza el método). Este uso se aplica tanto a los servlets como a los enterprise beans.
Puede ampliar la duración de una transacción local por encima de la duración de un método de componente EJB.
Las especificaciones EJB (Enterprise JavaBeans) restringen el uso de RMLT a métodos EJB únicos. Esta restricción es debida a que las especificaciones no tienen dispositivo de ámbito, más allá del límite del método impuesto por el contenedor, en el que se puede ampliar una RMLT. Se puede utilizar el valor de Extended Deployment de Límites de la sección Transacciones locales para proporcionar las ventajas siguientes:
- Ampliar de forma significativa los casos de uso de RMLT.
- Realizar interacciones conversacionales con gestores de recursos de una fase posible a través del soporte de sesiones de actividad.
Se puede utilizar una sesión de actividad para proporcionar un contexto distribuido con un límite que no sea más largo que un método único. Puede ampliar el uso de RMLT mas allá del límite de sesión de actividad mayor, que puede controlarlo un cliente. El límite de la sesión de actividad reduce la necesidad de utilizar transacciones distribuidas en las que las operaciones ACID sobre recursos múltiples no son necesarias. Esta ventaja se aplica mediante la valor de Extended Deployment de Límites, en la sección Transacciones locales, de sesión de actividad. Tales RMLT ampliadas pueden permanecer bajo el control de la aplicación o estar gestionadas por el contenedor, dependiendo del valor del descriptor de despliegue de Resolver en la sección Transacciones locales.
- Puede coordinar varios gestores de recursos de una fase.
- Para gestores de recursos sin soporte para la coordinación de transacción XA, un cliente puede utilizar los contextos de transacción local limitados por sesión de actividad. Dichos contextos proporcionan al cliente la posibilidad de controlar la dirección de finalización de las actualizaciones de recursos por parte de gestores de recursos de la misma forma que el cliente lo hace para gestores de recursos transaccionales. Un cliente puede arrancar una sesión de actividad e invocar sus beans de entidad en dicho contexto. Dichos beans pueden realizar sus RMLT dentro del ámbito de dicha sesión de actividad y retornar sin completar las RMLT. El cliente puede completar posteriormente la sesión de actividad en una dirección de retrotraimiento o compromiso y hacer que el contenedor maneje las RMLT limitadas por la sesión de actividad en dicha dirección coordinada.
- Puede utilizar LTC para reducir el número de conexiones que necesita.
- Los componentes de aplicación pueden compartir los LTC. Si los componentes obtienen conexiones con el mismo gestor de recursos, pueden compartir dicha conexión si encuentran la misma transacción global o LTC que puede compartirse. Para configurar dos componentes para que se ejecuten bajo el mismo LTC compartible, establezca el atributo Shareable de la sección de transacciones locales en el descriptor de despliegue de cada componente. Asegúrese de que la referencia de recursos en el descriptor de despliegue para cada componente utilice el valor predeterminado de Shareable para el elemento res-sharing-scope, si se especifica este elemento. Un LTC compartible puede reducir el número de RMLT que utiliza una aplicación. Por ejemplo, una aplicación que utilice llamadas include de módulo web con frecuencia puede compartir las conexiones del gestor de recursos entre estos módulos web, explotando LTC que se pueden compartir, o bien una transacción global, reduciendo las retenciones de bloques para los recursos.
Ejemplos de configuraciones de soporte de transacciones locales
En la lista siguiente se incluyen escenarios de ejemplo que utilizan transacciones locales, así como puntos a tener en cuenta cuando se decide la forma idónea de configurar el soporte de transacciones para una aplicación.
- Hay que arrancar y finalizar transacciones globales de forma explícita en la
aplicación (sólo servlets y beans de sesión de transacciones gestionadas por bean).
Para un bean de sesión, establecer el Tipo de transacción en Bean (para utilizar transacciones gestionadas por bean) en el descriptor de despliegue del componente. No es necesario hacerlo para servlets.
En un método, hay que acceder sólo a un recurso XA o no XA.
En el descriptor de despliegue del componente, en la sección Transacciones locales, establezca el atributo Resolver en ContainerAtBoundary. En la sección Transacciones de contenedor, establezca el tipo de transacción de contenedor en Soporta.
- Hay que acceder a varios recursos XA de forma atómica por medio de uno o más
métodos bean.
En el descriptor de despliegue del componente, en la sección Transacciones de contenedor, establezca el tipo de transacción de contenedor en Necesario, Requiere nuevo u Obligatorio.
Hay que acceder a varios recursos no XA en un método sin tener que gestionar sus propias transacciones locales.
En el descriptor de despliegue del componente, en la sección Transacciones locales, establezca el atributo Resolver en ContainerAtBoundary. En la sección Transacciones de contenedor, establezca el tipo de transacción de contenedor en No soportado.
- Hay que acceder a varios recursos no XA en un método y gestionarlos de forma
independiente.
En el descriptor de despliegue del componente, en la sección Transacciones locales, establezca el atributo Resolver en Aplicación y establezca el atributo Acción no resuelta en Retrotracción. En la sección Transacciones de contenedor, establezca el tipo de transacción de contenedor en No soportado.
Hay que acceder a uno o varios recursos que no sean XA a través de varias llamadas al método EJB sin tener que gestionar sus propias transacciones locales.
En el descriptor de despliegue del componente, en la sección Transacciones locales, establezca el atributo Resolver en ContainerAtBoundary y el atributo Límite en Sesión de actividad. En la sección Memoria caché de bean, establezca el atributo Activar en como Sesión de actividad. En la sección Transacciones de contenedor, establezca el tipo de transacción de contenedor en No soportado y el atributo de tipo ActivitySession en Necesario, Requiere Nuevo u Obligatorio.
Hay que acceder a varios recursos no XA a través de llamadas múltiples a métodos EJB y gestionarlos de forma independiente.
En el descriptor de despliegue del componente, en la sección Transacciones locales, establezca el atributo Resolver y el atributo Límite en Sesión de actividad. En la sección Memoria caché de bean, establezca el atributo Activar en como Sesión de actividad. En la sección Transacciones de contenedor, establezca el tipo de transacción de contenedor en No soportado y el atributo de tipo ActivitySession en Necesario, Requiere Nuevo u Obligatorio.
Supongamos que desea utilizar un recurso no XA con varios recursos RRS de dos fases.
La utilización de un recurso no XA en una transacción junto con recursos RRS está soportada siempre que se active una transacción global. Una transacción global está activa cuando el descriptor de despliegue para el tipo de transacción de contenedor se establece en Soporta, Necesario, Requiere nuevo u Obligatorio. Las transacciones globales también se activan para los despliegues gestionados por componente. El contenedor gestiona la finalización de la transacción local de recusos no XA junto con los recursos RRS.