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.

Java university

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.

¿Necesita un servidor de aplicaciones para gestionar transacciones?

El soporte de Spring Framework para la gestión de transacciones cambia las reglas tradicionales con respecto al requisito de un servidor de aplicaciones para una aplicación Java.

En particular, si hablamos exclusivamente de transacciones declarativas a través de clases EJB, no se requiere un servidor de aplicaciones. De hecho, incluso si su servidor de aplicaciones tiene capacidades JTA completas, es posible que aún descubra que las transacciones declarativas de Spring Framework brindan más funcionalidad y un modelo de programación más productivo que el CMT de EJB.

Normalmente, las capacidades JTA de un servidor de aplicaciones solo son necesarias si la aplicación necesita procesar transacciones a través de múltiples recursos, lo cual no es un requisito para muchas aplicaciones. En cambio, muchas aplicaciones de alto nivel utilizan una base de datos única y altamente escalable (como Oracle RAC). Gestores de transacciones independientes (como Atomikos Transactions y JOTM) son otra opción. Por supuesto, es posible que se requieran otras herramientas de servidor de aplicaciones, como Java Message Service (JMS) y Java EE Connector Architecture (JCA).

Spring Framework le permite elegir cuándo escalar su aplicación a un servidor de aplicaciones completamente cargado. Atrás quedaron los días en los que la única alternativa al uso de CMT desde EJB o JTA era escribir código con transacciones locales (como conexiones JDBC) y tener que lidiar con una importante reescritura de código si deseaba que ese código se ejecutara dentro de los límites de la administración por contenedor transacciones globales. En Spring Framework, solo necesita cambiar algunas de las definiciones de beans en el archivo de configuración (no el código).