Transações, quando deverá ser descartado e rolledback

Question

Eu estou tentando depurar um aplicativo (sob PostgreSQL) e me deparei com o seguinte erro: "Transação atual é abortada, comandos ignorados".

Tanto quanto eu posso entender uma "transação" é apenas uma noção relacionado à conexão de banco de dados subjacente.

Se a conexão tem um auto commit "false", você pode executar consultas através da mesma Declaração, desde que ele não está a falhar. Caso em que você deve reverter.

Se auto cometer é "verdade", então não importa, desde que todas as suas consultas são consideradas atômica.

Usando auto commit falsa, eu recebo o erro acima mencionado pelo PostgreSQL, mesmo quando um simples

select * from foo

falhar, o que me faz perguntar, em que SQLException (s) é uma "transação" considerado inválido e deve ser rolada apoiada ou não utilizada para outra consulta?

usando MacOS 10.5, Java 1.5.0_16, PostgreSQL 8.3 com o driver JDBC 8.1-407.jdbc3

Answer 1

Isso significa erro que uma das consultas enviadas em uma transação falhou, então o resto das consultas são ignoradas até o final da transação corrente (que será automaticamente um rollback). Para PostgreSQL a transação falhou, e será revertida em qualquer caso, após o erro com uma exceção. Você tem que tomar as medidas adequadas, uma das

1. descartar a declaração e começar de novo.
2. SAVEPOINT s na transação para ser capaz para voltar a esse ponto no tempo e tentar outro caminho. (Esta é a exceção)

consulta registrando para ver qual consulta é a falha e por quê.

Em qualquer caso, a resposta exata para sua pergunta é que qualquer SQLException deve significar uma reversão aconteceu quando o fim do comando de transação é enviado, que é quando um COMMIT ou ROLLBACK (ou END) é emitido. Esta é a forma como ele funciona, se você usar savepoints você ainda estará sujeito às mesmas regras, você só vai ser capaz de voltar para onde você salvou e tentar outra coisa.

Answer 2

Parece ser um comportamento característico de PostgreSQL que não é compartilhada pela maioria dos outros DBMS. Em geral (fora do PostgreSQL), você pode ter uma operação falhar por causa de um erro e, em seguida, na mesma transação, pode tentar ações alternativas que terão sucesso, compensando o erro. Um exemplo: considere uma operação de fusão (insert / update). Se você tentar inserir o novo registro, mas descobrir que ele já existe, você pode alternar para uma operação UPDATE que muda o registro existente em seu lugar. Isso funciona bem em todos os principais DBMS. Não estou certo de que ele não funciona no PostgreSQL, mas as descrições que eu vi em outros lugares, bem como nesta questão, sugerem que quando os meios ENVIE tentativas que qualquer outra atividade na transação está fadado ao fracasso também. Qual é a melhor draconiana e, na pior 'inutilizável'.