Transacciones, cuando deben descartarse y revertirse

Question

Estoy tratando de depurar una aplicación (en PostgreSQL) y encontré el siguiente error: " la transacción actual se cancela, los comandos se ignoran " ;.

Hasta donde puedo entender una " transacción " es solo una noción relacionada con la conexión de base de datos subyacente.

Si la conexión tiene una confirmación automática " falso " ;, puede ejecutar consultas a través de la misma Declaración siempre que no falle. En cuyo caso, debería retroceder.

Si la confirmación automática es " verdadero " entonces no importa mientras todas sus consultas se consideren atómicas.

Al usar el compromiso automático falso, recibo el error mencionado por PostgreSQL incluso cuando un simple

select * from foo

falla, lo que me hace preguntar, bajo qué SQLException (s) es una " transacción " ¿se considera inválido y debe ser respaldado o no utilizado para otra consulta?

  

usando MacOS 10.5, Java 1.5.0_16, PostgreSQL 8.3 con el controlador JDBC 8.1-407.jdbc3

Answer 1

Ese error significa que una de las consultas enviadas en una transacción ha fallado, por lo que el resto de las consultas se ignoran hasta el final de la transacción actual (que será automáticamente una reversión). Para PostgreSQL, la transacción ha fallado y se revertirá en cualquier caso después del error con una excepción. Tienes que tomar las medidas apropiadas, una de

1. descarte la declaración y comience de nuevo.
2. use SAVEPOINT s en la transacción para poder volver a ese punto en el tiempo e intentar otro camino. (Esta es la excepción)

Habilite registro de consultas para ver qué consulta es la que falla. y por qué.

En cualquier caso, la respuesta exacta a su pregunta es que cualquier excepción SQLException debe significar que se produjo una reversión cuando se envía el comando de finalización de la transacción, es decir, cuando se emite un COMMIT o ROLLBACK (o END). Así es como funciona, si usas puntos de guardado todavía estarás obligado por las mismas reglas, solo podrás volver a donde guardaste e intentar otra cosa.

Answer 2

Parece ser un comportamiento característico de PostgreSQL que no es compartido por la mayoría de los otros DBMS. En general (fuera de PostgreSQL), puede hacer que una operación falle debido a un error y luego, en la misma transacción, puede probar acciones alternativas que tendrán éxito, compensando el error. Un ejemplo: considere una operación de fusión (inserción / actualización). Si intenta INSERTAR el nuevo registro pero encuentra que ya existe, puede cambiar a una operación ACTUALIZAR que cambia el registro existente. Esto funciona bien en todos los DBMS principales. No estoy seguro de que no funcione en PostgreSQL, pero las descripciones que he visto en otros lugares, así como en esta pregunta, sugieren que cuando el intento INSERT significa que cualquier otra actividad en la transacción está condenada al fracaso también. Lo cual es, en el mejor de los casos, draconiano y, en el peor, 'inutilizable'.