Transacciones de Yakarta

Las Transacciones de Jakarta (JTA; anteriormente API de transacciones de Java), una de las API de EE de Jakarta, permite que se realicen transacciones distribuidas a través de múltiples recursos X/Open XA en un entorno Java. JTA fue una especificación desarrollada bajo el Java Community Process como JSR 907. JTA proporciona:

• demarcación de los límites de transacción
• X/Open XA API permitiendo que los recursos participen en transacciones.

Arquitectura X/Open XA

En la arquitectura X/Open XA, un administrador de transacciones o un monitor de procesamiento de transacciones (monitor TP) coordina las transacciones a través de múltiples recursos, como bases de datos y colas de mensajes. Cada recurso tiene su propio administrador de recursos. El administrador de recursos normalmente tiene su propia API para manipular el recurso, por ejemplo, la API JDBC para trabajar con bases de datos relacionales. Además, el administrador de recursos permite que un monitor de TP coordine una transacción distribuida entre su propio administrador de recursos y otros. Finalmente, está la aplicación que se comunica con el monitor TP para iniciar, confirmar o revertir las transacciones. La aplicación también se comunica con los recursos individuales mediante su propia API para modificar el recurso.

Implementación JTA de la arquitectura X/Open XA

La API de JTA consta de clases en dos paquetes de Java:

• javax.transaction
• javax.transaction.xa

JTA se basa en la arquitectura X/Open XA, pero define dos API diferentes para demarcar los límites de las transacciones. Distingue entre un servidor de aplicaciones como un servidor EJB y un componente de aplicación. Proporciona una interfaz, javax.transaction.TransactionManager, que utiliza el propio servidor de aplicaciones para iniciar, confirmar y revertir las transacciones. Proporciona una interfaz diferente, javax.transaction.UserTransaction, que utiliza el código de cliente general, como un servlet o un EJB, para administrar las transacciones.

La arquitectura JTA requiere que cada administrador de recursos implemente la interfaz javax.transaction.xa.XAResource para ser administrado por el monitor TP. Como se indicó anteriormente, cada recurso tendrá su propia API específica, por ejemplo:

• bases de datos relacionales usan JDBC
• los servicios de mensajería usan JMS
• Los recursos de EIS generalizados (Sistema de Información de Inicio) utilizan Java EE Connector API.

Interfaz de programación de aplicaciones

La API de transacciones de Jakarta consta de tres elementos: una interfaz de demarcación de transacciones de aplicaciones de alto nivel, una interfaz de administrador de transacciones de alto nivel destinada a un servidor de aplicaciones y una asignación Java estándar del protocolo X/Open XA destinada a un servidor transaccional. administrador de recursos.

Interfaz de transacción de usuario

La interfaz javax.transaction.UserTransaction proporciona a la aplicación la capacidad de controlar los límites de las transacciones mediante programación. Esta interfaz se puede utilizar por programas cliente Java o beans EJB.

El método UserTransaction.begin() inicia una transacción global y asocia el transacción con el subproceso de llamada. La asociación de transacción a subproceso se administra transparentemente por el Transaction Manager.

No se requiere soporte para transacciones anidadas. El método UserTransaction.begin lanza la excepción NotSupportedException cuando el subproceso de llamada ya está asociado con una transacción y la implementación del administrador de transacciones no admite transacciones anidadas actas.

La propagación del contexto de transacción entre programas de aplicación es proporcionada por el implementaciones subyacentes del administrador de transacciones en las máquinas cliente y servidor. El formato de contexto de transacción utilizado para la propagación depende del protocolo y debe ser negociado entre el cliente y los hosts del servidor. Por ejemplo, si el administrador de transacciones es una implementación de la especificación JTS, utilizará el contexto de transacción formato de propagación como se especifica en la especificación CORBA OTS 1.1. Transacción la propagación es transparente para los programas de aplicación.

@Anotación transaccional

La anotación javax.transaction.Transactional proporciona a la aplicación la capacidad de controlar los límites de las transacciones declarativamente. Esta anotación se puede aplicar a cualquier clase que la especificación Jakarta EE se define como un bean gestionado (que incluye beans gestionados por CDI).

El ejemplo de código siguiente ilustra el uso de @Transactional en un bean gestionado CDI con ámbito de solicitud:

@RequestScopedpúblico clase Ejemplo {} @Transactional público vacío Foo() {} // Una transacción está activa aquí // Hacer trabajo } // Después de que el método devuelve la transacción se comete o vuelve a rodar}

El comportamiento transaccional se puede configurar a través de un atributo en la anotación. Las opciones disponibles reflejan fielmente las de la especificación EJB.

Anotación @TransactionScoped

La anotación javax.transaction.TransactionScoped proporciona a la aplicación la capacidad de declarar que el alcance durante el cual vive un bean está vinculado al tiempo que una transacción determinada está activa.

El ejemplo de código siguiente ilustra el uso de @TransactionScoped en un bean gestionado CDI con ámbito de solicitud:

@TransactionScopedpúblico clase TxScopedBean {} público int Número; público int getNumber() {}retorno Número; público vacío setNumber()int Número) {}esto.Número = Número;}@RequestScopedpúblico clase Ejemplo {} @Inject privado TxScopedBean txScopedBean; @Transactional público vacío Foo() {} txScopedBean.setNumber()1); } @Transactional público vacío bar() {} Sistema.Fuera..impresión()tXscopedBean.getNumber()); }}

Si primero se llama al método foo() en una instancia administrada de ExampleBean y luego se llama al método bar(), el número impreso será 0 y no 1 Esto se debe a que cada método tenía su propia transacción y por lo tanto su propia instancia de TxScopedBean. Por lo tanto, el número 1 que se estableció durante la llamada a foo() no se verá durante la llamada a bar().

Soporte de UserTransaction en el servidor EJB

Los servidores EJB son necesarios para admitir la interfaz UserTransaction para uso de EJB beans con el valor BEAN en la anotación javax.ejb.TransactionManagement (esto se denomina transacciones gestionadas por beans o BMT). La transacción de usuario se expone a los componentes EJB a través de la interfaz EJBContext utilizando el getUserTransaction, o directamente mediante inyección usando la anotación general @Resource. Por lo tanto, una aplicación EJB no interactúa con el Transaction Manager directamente para la demarcación de transacciones; en cambio, el bean EJB se basa en el servidor EJB para proporcionar soporte para todo su trabajo de transacción como se define en el Especificación de Enterprise Beans de Jakarta. (La interacción subyacente entre el EJB El servidor y la TM son transparentes para la aplicación; la carga de implementar la gestión de transacciones recae en el contenedor EJB y el proveedor del servidor).

El ejemplo de código siguiente ilustra el uso de UserTransaction a través de transacciones gestionadas por beans en un bean de sesión EJB:

@Stateless@TransactionManagement()BEAN)público clase Ejemplo {} @Resource privado UserTransaction utx; público vacío Foo() {} // iniciar una transacción utx.comenzar(); // Hacer trabajo // Compromiso utx.commit(); }}

Alternativamente, UserTransaction se puede obtener de SessionContext:

@Stateless@TransactionManagement()BEAN)público clase Ejemplo {} @Resource privado SessionContext ctx; público vacío Foo() {} UserTransaction utx = ctx.# UserTransaction(); // iniciar una transacción utx.comenzar(); // Hacer trabajo // Compromiso utx.commit(); }}

Sin embargo, tenga en cuenta que en el ejemplo anterior, si se omite la anotación @TransactionManagement(BEAN), una transacción JTA se inicia automáticamente cada vez que se llama a foo() y se activa automáticamente. confirmado o revertido cuando se sale de foo(). Por lo tanto, no es necesario hacer uso de una UserTransaction en la programación EJB, pero podría ser necesario para un código muy especializado.

Soporte de UserTransaction en JNDI

UserTransaction debe estar disponible en java:comp/UserTransaction (si se instala una implementación de JTA en el entorno).