java - example - Implementación de soporte para transacciones anidadas usando JDBC 3.0

java transaction api

Question

nuestra aplicación heredada usa JDBC 3.0. admite transacciones mediante la implementación de su propio administrador de transacciones que es capaz de devolver la misma conexión JDBC para cada subproceso. El problema que descubrí recientemente es que no admite transacciones anidadas: si una transacción se inicia dentro de otra transacción, todos los SQL que se ejecutan en el contexto de la transacción interna se ejecutarán utilizando la misma conexión de base de datos, y cuándo se ha comprometido o revertido, confirmará o retrotraerá automáticamente todos los cambios a partir de la transacción externa.

Por lo que yo entiendo, puedo implementar el soporte para transacciones anidadas utilizando puntos de almacenamiento JDBC 3.0: cada vez que se inicia una transacción anidada, puedo establecer un nuevo punto de rescate para la conexión actual. Después, si la transacción anidada se retrotrae, simplemente retrocederé a este punto de rescate. Si, por otro lado, está comprometido, simplemente no haré nada. Solo la confirmación de la transacción más externa guardará los cambios en el db.

¿Es esto correcto? ¿Este enfoque tiene algún defecto? Si es así, ¿cuáles son mis posibilidades?

Gracias.

Answer 1

Las transacciones son un poco complicadas y no se pueden ver realmente desde una capa JDBC, sino con la base de datos subyacente. Hablaré de Oracle a partir de ahora, ya que es con lo que tengo más experiencia. En Oracle, si inicia una transacción, puede volver a los puntos de rescate dentro de la transacción, pero no puede comprometerse usando puntos de rescate. Entonces, supongamos que empiezo una transacción y tengo tres puntos de rescate, A, B y C. Puedo avanzar felizmente y retroceder a A, B o C, pero una vez que se compromete, ha comenzado una nueva transacción y ahora A, B y C ya no son válidos. Espero que esto ayude a responder tu pregunta.

Answer 2

Puede haber dependencias en el código que esperan que el compromiso se realice en lugar de posponerse (por ejemplo, si el nivel de aislamiento está establecido en TRANSACTION_READ_COMMITTED).

Considere arreglar su administrador de transacciones para hacer la transacción anidada en una conexión separada.

ACTUALIZACIÓN: parece que el marco Spring utiliza SavePoints para proporcionar transacciones anidadas. Mi suposición es que simplemente ignoran el problema del modo de aislamiento.

Answer 3

Puede probar el soporte de transacción anidado en Atomikos TransactionsEssentials .

Sin embargo, las transacciones anidadas en un DBMS generalmente están restringidas de la siguiente manera:

- sus transacciones anidadas comparten la misma transacción de base de datos, lo que permite el acceso a datos compartidos a costa de la granularidad de reversión (usted revierte todo)

-o sus transacciones anidadas se asignan (por Atomikos) a diferentes transacciones de bases de datos subyacentes, a costa de no permitir el acceso a datos compartidos para los datos de punto de acceso

Esta falta de coincidencia se debe a la naturaleza ACID de las transacciones de la base de datos. Finalmente, todo su acceso DBMS está destinado a suceder en dicha transacción de base de datos.

Si quiere envolver algo usted mismo, el enfoque de punto de guardado que menciona suena prometedor, pero entonces probablemente deba asegurarse de probarlo extensamente.

El mejor chico