Estou vendo o seguinte rastreamento de pilha (truncado) no arquivo server.log do JBoss 7.1.1 Final:
Caused by: org.postgresql.util.PSQLException:
ERROR: current transaction is aborted, commands ignored until end of
transaction block
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2102)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1835)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:512)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:374)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:302)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_23]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_23]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_23]
at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_23]
at org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$StatementHandler.invoke(AbstractJdbc23PooledConnection.java:455)
at $Proxy49.executeUpdate(Unknown Source) at org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:371)
at org.infinispan.loaders.jdbc.TableManipulation.executeUpdateSql(TableManipulation.java:154) [infinispan-cachestore-jdbc-5.1.2.FINAL.jar:5.1.2.FINAL]
... 154 more
A inspeção do arquivo de log do Postgres revela as seguintes instruções:
STATEMENT: SELECT count(*) FROM ISPN_MIXED_BINARY_TABLE_configCache
ERROR: current transaction is aborted, commands ignored until end of transaction block
STATEMENT: CREATE TABLE ISPN_MIXED_BINARY_TABLE_configCache(ID_COLUMN VARCHAR(255) NOT NULL, DATA_COLUMN BYTEA, TIMESTAMP_COLUMN BIGINT, PRIMARY KEY (ID_COLUMN))
ERROR: relation "ispn_mixed_binary_table_configcache" does not exist at character 22
Estou usando o Infinispan enviado com o JBoss 7.1.1 Final, que é 5.1.2.Final.
Então é isso que eu acho que está acontecendo:
- O Infinispan tenta executar a
SELECT count(*)...
instrução para ver se há algum registro noISPN_MIXED_BINARY_TABLE_configCache
; - O Postgres, por algum motivo, não gosta desta declaração.
- O Infinispan ignora isso e avança com a
CREATE TABLE
declaração. - O Postgres vomita porque ainda pensa que é a mesma transação, que o Infinispan não conseguiu reverter, e essa transação é derivada da primeira
SELECT count(*)...
instrução.
O que esse erro significa e alguma idéia de como contorná-lo?
postgresql
jboss
infinispan
Jimidy
fonte
fonte
PSQLException: current transaction is aborted...
( acima25P02
) e talvez tambémJPA
ouHibernate
. Finalmente, foi devido ao nosso (bom!) Uso de Logback alimentado com umtoString()
objeto DAO sobrecarregado que causou o erro e foi bem engolido (mas despercebido por mim):log.info( "bla bla: {}", obj )
produzidobla bla: [FAILED toString()]
. alterá-lo paralog.info( "bla bla: {}", String.valueOf( obj )
torná-lo seguro para nulos, mas não engoli-lo e, portanto, deixando a transação aberta com falha em uma consulta não relacionada.Respostas:
Eu recebi esse erro usando Java e postgresql fazendo uma inserção em uma tabela. Ilustrarei como você pode reproduzir este erro:
Resumo:
O motivo para você obter esse erro é porque você inseriu uma transação e uma das suas Consultas SQL falhou, e você engoliu a falha e a ignorou. Mas isso não foi suficiente, então você usou a mesma conexão, usando a mesma transação para executar outra consulta. A exceção é lançada na segunda consulta formada corretamente, porque você está usando uma transação quebrada para realizar trabalho adicional. O Postgresql, por padrão, impede você de fazer isso.
Estou a usar:
PostgreSQL 9.1.6 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2), 64-bit".
Meu driver do postgresql é:
postgresql-9.2-1000.jdbc4.jar
Usando a versão java:
Java 1.7
Aqui está a instrução create da tabela para ilustrar a exceção:
O programa Java causa o erro:
O código acima produz esta saída para mim:
Soluções alternativas:
Você tem poucas opções:
Solução mais simples: não esteja em uma transação. Defina
connection.setAutoCommit(false);
comoconnection.setAutoCommit(true);
. Funciona porque o SQL com falha é apenas ignorado como uma instrução sql com falha. Você pode falhar nas instruções sql o quanto quiser e o postgresql não irá impedi-lo.Continue sendo uma transação, mas quando detectar que o primeiro sql falhou, reverter / reiniciar ou confirmar / reiniciar a transação. Em seguida, você pode continuar falhando quantas consultas sql nessa conexão com o banco de dados desejar.
Não pegue e ignore a exceção lançada quando uma instrução sql falha. Em seguida, o programa será interrompido na consulta incorreta.
Em vez disso, adquira o Oracle. O Oracle não lança uma exceção quando você falha em uma consulta em uma conexão em uma transação e continua usando essa conexão.
Em defesa da decisão do postgresql de fazer as coisas desta maneira ... A Oracle estava deixando você mole no meio, deixando você fazer coisas idiotas e ignorando isso.
fonte
rollback()
noConnection
quando umSQLException
é pego. [ De qualquer forma , percebi que isso está alinhado com a filosofia do PostgreSQL de forçar o usuário a deixar tudo explícito, enquanto a Oracle tem a filosofia de cuidar implicitamente de muitas coisas.]or commit/restart the transaction
. Como posso ver, não há como confirmar após a exceção. Quando tento cometer - PostgreSQL fazerrollback
psql
. (1) inicie uma transação, (2) emita algumas instruções válidas, (3) emita uma declaração inválida, (4) commit -> psql reverterá em vez de confirmar.savepoints
para reverter para o ponto anterior à atualização / inserção. Consulte stackoverflow.com/a/28640557/14731 para obter um código de exemplo.Verifique a saída antes da declaração que causou
current transaction is aborted
. Isso normalmente significa que o banco de dados lançou uma exceção que seu código ignorou e agora espera que as próximas consultas retornem alguns dados.Portanto, agora você tem uma incompatibilidade de estado entre seu aplicativo, que considera as coisas boas e o banco de dados, que exige que você reverta e reinicie sua transação desde o início.
Você deve capturar todas as exceções e transações de reversão nesses casos.
Aqui está uma questão semelhante.
fonte
SQL
que causou o problema, terá algum campo para eliminá-lo usando a extensibilidade do PostgreSQL.Eu acho que a melhor solução é usar java.sql.Savepoint.
Antes de executar a consulta que pode lançar o SQLException, use o método Connection.setSavepoint () e, se a exceção for lançada, você reverterá somente para esse ponto de salvamento, e não reverterá todas as transações.
Código de exemplo:
fonte
Houve algum trabalho realizado no driver JDBC do postgresql, relacionado a esse comportamento:
consulte https://github.com/pgjdbc/pgjdbc/pull/477
Agora é possível, definindo
na conexão (consulte https://jdbc.postgresql.org/documentation/head/connect.html ) para evitar o syndroma 'a transação atual foi abortada'.A sobrecarga devido ao tratamento de um ponto de salvamento em torno da execução da instrução é mantida muito baixa (consulte o link acima para obter detalhes).
fonte
No Ruby on Rails PG, criei uma migração, migrei meu banco de dados, mas esqueci de reiniciar meu servidor de desenvolvimento. Eu reiniciei meu servidor e funcionou.
fonte
A razão para esse erro é que há outro banco de dados antes que a operação incorreta que leva à operação atual do banco de dados não possa ser realizada (eu uso a tradução do google para traduzir meu chinês para inglês)
fonte
O problema foi corrigido no Infinispan 5.1.5.CR1: ISPN-2023
fonte
Você precisa reverter. O driver do JDBC Postgres é muito ruim. Mas se você deseja manter sua transação e reverter esse erro, pode usar pontos de salvamento:
Leia mais aqui:
http://www.postgresql.org/docs/8.1/static/sql-savepoint.html
fonte
Eu tive o mesmo problema, mas percebi que há uma tabela com o mesmo nome no banco de dados. Depois de excluir, consegui importar o arquivo.
fonte
Esse é um comportamento muito estranho do PostgreSQL; ele não está "alinhado com a filosofia do PostgreSQL de forçar o usuário a tornar tudo explícito" - como a exceção foi capturada e ignorada explicitamente. Portanto, mesmo essa defesa não se sustenta. A Oracle, nesse caso, se comporta muito mais amigável e (quanto a mim) corretamente - deixa uma opção para o desenvolvedor.
fonte
Isso pode acontecer se você estiver sem espaço em disco no volume.
fonte
Acabei de encontrar o mesmo erro. Consegui descobrir a causa raiz ativando as informações log_statement e log_min_error_statement no PostgreSQL local.
Eu indiquei isso
fonte
Estou usando o JDBI com o Postgres e encontrei o mesmo problema, ou seja, após uma violação de alguma restrição de uma declaração de transação anterior, as instruções subsequentes falhariam (mas depois de esperar um pouco, digamos 20 a 30 segundos, o problema desaparece )
Após algumas pesquisas, descobri que o problema era fazer transações "manualmente" no meu JDBI, ou seja, cercava minhas declarações com BEGIN; ... COMMIT; e acaba por ser o culpado!
No JDBI v2, posso apenas adicionar a anotação @Transaction, e as instruções em @SqlQuery ou @SqlUpdate serão executadas como uma transação, e o problema acima mencionado não ocorrerá mais!
fonte
No meu caso, eu estava recebendo esse erro porque meu arquivo estava corrompido. Enquanto iterava os registros dos arquivos, estava me dando o mesmo erro.
Pode ser que no futuro ajude a alguém. Essa é a única razão para postar esta resposta.
fonte
Uso spring com
@Transactional
anotação e pego a exceção e, por alguma exceção, tentarei novamente 3 vezes.Para posgresql, quando há exceção, você não pode usar a mesma conexão para confirmar mais. Você deve reverter primeiro.
No meu caso, uso o
DatasourceUtils
para obter a conexão atual e ligarconnection.rollback()
manualmente. E a chamada de método recrutar para tentar novamente.fonte
Eu estava trabalhando com o jpa de inicialização por mola e corrigido implementando @EnableTransactionManagement
O arquivo anexado pode ajudá-lo.
fonte
Eu estava trabalhando com o jpa de inicialização por mola e corrigido implementando @EnableTransactionManagement
O arquivo anexado pode ajudá-lo.
fonte
Tente isto
COMMIT;
Eu corro isso no pgadmin4. Isso pode ajudar. Tem a ver com o comando anterior parar prematuramente
fonte
Altere o nível de isolamento de leitura repetível para leitura confirmada.
fonte
Defina conn.setAutoCommit (false) como conn.setAutoCommit (true)
Confirme as transações antes de iniciar uma nova.
fonte