tutorial - Java EE: ¿Por qué usar JTA directamente?

que significa jta

Question

Estoy tratando de entender JTA y estoy usando Bitronix como el administrador de transacciones de su elección (solo por el bien de aprender y entender). Estoy mirando el código dentro de la guía de referencia de Bitronix aquí y me pregunto a mí mismo: si estoy usando JDBC, que a su vez es transaccional (la Connection puede comprometerse / retrotraerse), ¿por qué querría escribir un código como ese? ?!?!

Ahora tal vez el objetivo de ese fragmento de código era simplemente demostrar cómo usar Bitronix / JTA sobre un almacén de datos transaccional existente, pero aún no obtengo los beneficios inherentes que ofrece.

Entonces, este fragmento de código me hizo pensar: " Si las dos únicas fuentes de datos principales que utiliza son bases de datos y agentes de mensajes, y usa JDBC / JMS para comunicarse con ellos, respectivamente, y estos dos estándares (JDBC / JMS) ya son transaccionales, entonces ¿por qué necesitarías usar JTA en absoluto?!?! "

¿Es JTA una especie de API "interna" de Java EE que utilizan JDBC, JPA, JMS, etc.? y solo está expuesto públicamente para el 1% de las personas que quieren hacer algo loco con eso? ¿O me estoy perdiendo la idea / aplicabilidad de JTA por completo?

Creo que podría imaginar dos casos de uso que no sean JDBC ni JMS para acceder directamente a JTA, pero como soy muy confuso con JTA, no tengo idea si estos casos están desviados o no:

• Quizás tengas un sistema de E / S complicado en tu aplicación y tengas varios hilos que leen / escriben desde el mismo archivo en el disco. Tal vez debería hacer que cada hilo use una transacción para escribir en este archivo. (¿¡¿Si no?!?)
• Quizás tenga una máquina de estados POJO que represente el estado de un sistema, y ​​múltiples hilos pueden modificar la máquina. Quizás tendrías que cada hilo usa una transacción para alterar el estado de la máquina. (¿¡¿Si no?!?)

Supongo que la raíz de mi pregunta es:

• Si mis llamadas JPA (Hibernate) y / o JDBC ya son transaccionales, ¿por qué querría incluirlas en JTA begin-> commit / rollback block? Lo mismo para JMS y sistemas de mensajería.
• Fuera de JPA / JDBC / JMS, ¿qué casos de uso existen para usar JTA para tramitar una serie de operaciones?

¡Gracias por adelantado!

Answer 1

Es más que solo deshacer la transacción abierta, JTA proporciona una interfaz XAResource que los proveedores pueden implementar, su controlador JDBC y su proveedor JMS ya lo harán y usted podrá implementar el suyo propio. Esto se basa en un estándar abierto y probablemente valga la pena leerlo.

Ahora, ¿por qué querríamos esto?

Considere el ejemplo de Matthews en un desastre:

Begin DB Transaction
Set AccountBalance $100 lower for Account #345 in database
Add JMS Message "Transfer $100 to OtherBank Account #987" to queue
*** DB power is unplugged while committing DB Transaction ***

Lamentablemente, el mensaje JMS ha ido al otro banco, este es un problema muy real con las transacciones distribuidas.

Con XA, así es como se desarrollará el escenario:

DB Transation starts XA Transaction
Set AccountBalance $100 lower for Account #345 in database
JMS Connection joins XA Transaction
Add JMS Message "Transfer $100 to OtherBank Account #987" to queue
Everything went okay and JTA context is ready to commit.
DB and JMS both agree that they are capable of commiting.
JTA instructs DB and JMS to commit.
All members of the transaction commit.

Ahora puede preguntar qué pasa si el enchufe de alimentación se saca durante la confirmación final del DB. Bien, la cola JMS se habrá comprometido, sin embargo, la transacción XA permanecerá abierta hasta que el DB esté nuevamente disponible, momento en el que instruirá al DB para que confirme (el DB nos prometió que puede comprometerse, esto es parte de ser compatible con XA )

Lo que REALMENTE es genial acerca de JTA es que puedes implementar fácilmente tu propio XAResource personalizado y vincularlo a este gran marco.

ACTUALIZAR

Entonces, para responder a su pregunta sobre cuándo implementar transacciones personalizadas, puede preguntarse lo siguiente:

1. ¿Su estado o archivo personalizado NO PUEDE ser el bloque de código final en el alcance de la transacción?
2. ¿Necesita revertir su estado / archivo personalizado cuando falla un sistema externo (es decir, DB o JMS)?
3. ¿Es un getRollbackOnly () y setRollbackOnly () simple para sistemas externos, junto con el manejo de compensación (es decir, revertir el estado / archivo personalizado explícitamente) para su código personalizado insuficiente?

Si la respuesta a 1, 2 y 3 es SÍ, es probable que desee un XAResource personalizado, de lo contrario, creo que probablemente sea excesivo.

Sin embargo, si su código es un marco o una biblioteca que se utilizará para la lógica de negocios en el espacio de Java EE, ¡puede implementar un XAResource para ello!

Answer 2

Puede tener una transacción que cubra tanto la base de datos como el servicio de mensajes. No sé de ninguna manera de hacer eso sin JTA.

Ejemplo conceptual simple. El código exacto no es importante:

Comience la Transacción JTA

Establezca AccountBalance $ 100 más bajo para Account # 345 en la base de datos

Agregue el mensaje JMS "Transferir $ 100 a la cuenta de otro banco # 987" para hacer cola

Commit JTA Transaction

OtherBank es un banco separado, y suponemos que se comunica con él a través de JMS.

The Begin Transaction and Commit son manejados por JTA. Si no se puede agregar a la cola, la extracción también se retrotrae automáticamente.

La vida real no es tan simple, pero esto debería darte una idea.

EDITAR:

JTA se puede usar en cualquier momento en que parte del sistema pueda implementar correctamente XAResource . Al implementar eso, un recurso puede participar en transacciones distribuidas. A primera vista, ambos ejemplos propuestos podrían implementar XAResource .

"un sistema de E / S complicado en su aplicación y tener varios hilos que leen / escriben desde el mismo archivo en el disco". - Esto parece ser una base de datos, si lo piensas bien.

"Quizás tengas una máquina de estados POJO que represente el estado de un sistema, y ​​múltiples hilos pueden modificar la máquina". - Esto definitivamente podría ser un candidato, si los cambios pueden aislarse lo suficiente.

Creo que la primera parte de la rúbrica es básicamente que los recursos lógicamente podrían ser XAResource s. En otras palabras, el concepto de ACID es significativo. El segundo es que es posible y vale la pena el esfuerzo implementar esa interfaz (donde aún no está implementada).

Answer 3

En mi opinión, la primera consideración es descololar el administrador de TX y el sistema de TX.

Cuando diseño mi aplicación, la palabra Transactional marca mi intención de hacer algo ACID. Quiero poner esta intención en mi código comercial ya que esto debe ser impulsado por una necesidad comercial.

Espero que algo mágico (mi contenedor en la vida real) tejerá mis intenciones de tx correctamente, dependiendo del sistema TX subyacente (base de datos, jms broker, etc.)

Además, JTA define algunas interfaces para permitir la integración entre un sistema JTA existente y un sistema TX (eventualmente nuevo, eventualmente exótico). Por ejemplo: GigaSpaces XAP es una cuadrícula de datos en memoria. No es JMS, no SQL, pero es fácil de usar, ya que proporciona una integración JTA . Podríamos citar muchos otros productos ...

Obviamente, el ejemplo asesino es el soporte para transacciones XA entre diferentes sistemas (le doy un punto a Justin). Mi punto es decir que JTA tiene valor incluso si no usas transacciones XA.