Gestión de transacciones

El soporte integral para transacciones es una de las razones más convincentes para utilizar Spring Framework. Spring Framework proporciona una abstracción consistente para la gestión de transacciones que proporciona los siguientes beneficios:

• Modelo de programación coherente para varias API de transacciones, como Java Transaction API (JTA), JDBC, Hibernate y Java Persistence API (JPA).

• Soporte para la gestión de transacciones declarativas.

• API simplificada para la gestión de transacciones programáticas en lugar de API de transacciones complejas como JTA.

• Excelente integración con las abstracciones de acceso a datos de Spring.

Beneficios del modelo de soporte de transacciones de Spring Framework

Tradicionalmente, los desarrolladores de Java EE han tenido dos opciones para gestionar transacciones: a través de transacciones globales o locales, las cuales tienen serias limitaciones. La gestión de transacciones globales y locales se analiza en las dos secciones siguientes, seguidas de una descripción de cómo el soporte de gestión de transacciones de Spring Framework supera las limitaciones de los modelos de transacciones globales y locales.

Transacciones globales

Las transacciones globales le permiten trabajar con múltiples recursos transaccionales, normalmente bases de datos relacionales y colas de mensajes. El servidor de aplicaciones gestiona transacciones globales a través de JTA, que es una API engorrosa (en parte debido a su modelo de excepción). Además, UserTransaction de JTA generalmente debe recuperarse de JNDI, lo que significa que también debe usar JNDI para usar JTA. El uso de transacciones globales limita cualquier posible reutilización del código de la aplicación, ya que JTA normalmente solo está disponible en el entorno del servidor de aplicaciones.

Anteriormente, la forma preferida de utilizar transacciones globales era utilizar EJB Container Managed Transactions (CMT). CMT es una forma de gestión de transacciones declarativa (a diferencia de la gestión de transacciones programática). CMT de EJB elimina la necesidad de realizar búsquedas relacionadas con transacciones a través de JNDI, aunque el uso de EJB requiere el uso de JNDI. Esto elimina la mayor parte, aunque no del todo, de la necesidad de escribir código Java para gestionar transacciones. Un inconveniente importante es que CMT está vinculado al JTA y al entorno del servidor de aplicaciones. Además, sólo está disponible si elige implementar la lógica empresarial dentro de las clases EJB (o al menos dentro de la fachada transaccional EJB). Las desventajas de EJB en general son tan importantes que su uso deja de ser atractivo, especialmente si se compara con alternativas adecuadas para la gestión de transacciones declarativas.

Transacciones locales

Las transacciones locales son específicas de los recursos, como es el caso de una transacción asociada con una conexión JDBC. Las transacciones locales pueden ser más fáciles de usar, pero tienen un inconveniente importante: no pueden manejar múltiples recursos transaccionales. Por ejemplo, el código que gestiona transacciones mediante una conexión JDBC no puede ejecutarse en una transacción JTA global. Debido a que el servidor de aplicaciones no participa en la gestión de transacciones, no puede garantizar el funcionamiento correcto de múltiples recursos. (Vale la pena señalar que la mayoría de las aplicaciones utilizan un único recurso de transacción). Otra desventaja es que las transacciones locales son agresivas en su modelo de programación.

El modelo de programación consistente de Spring Framework

Spring elimina las deficiencias de las transacciones globales y locales. Esto permite a los desarrolladores de aplicaciones utilizar un modelo de programación coherente en cualquier entorno. Usted escribe su código una vez y, a su vez, puede utilizar diferentes estrategias de gestión de transacciones en diferentes entornos. Spring Framework proporciona gestión de transacciones tanto declarativa como programática. La mayoría de los usuarios prefieren la gestión de transacciones declarativa, que es lo que recomendamos en la mayoría de los casos.

Al gestionar transacciones mediante programación, los desarrolladores se ocupan de la abstracción de transacciones de Spring Framework, que puede ejecutarse en cualquier infraestructura de transacciones subyacente. Cuando se utiliza el modelo declarativo preferido, los desarrolladores normalmente escriben poco o ningún código relacionado con la gestión de transacciones y, por lo tanto, no dependen de la API de transacciones de Spring Framework ni de ninguna otra API de transacciones.