PSQLException: la transaction en cours est abandonnée, les commandes ignorées jusqu'à la fin du bloc de transaction

Je vois le stacktrace suivant (tronqué) dans le fichier server.log de 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

L'inspection du fichier journal Postgres révèle les déclarations suivantes:

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

J'utilise l'Infinispan livré avec JBoss 7.1.1 Final, qui est 5.1.2.Final.

Voilà donc ce que je pense qu'il se passe:

• Infinispan tente d'exécuter l' SELECT count(*)...instruction afin de voir s'il y a des enregistrements dans le ISPN_MIXED_BINARY_TABLE_configCache;
• Postgres, pour une raison quelconque, n'aime pas cette affirmation.
• Infinispan ignore cela et poursuit sa CREATE TABLEdéclaration.
• Postgres barfs parce qu'il pense toujours que c'est la même transaction, qu'Infinispan n'a pas réussi à annuler, et cette transaction est tirée de la première SELECT count(*)...instruction.

Que signifie cette erreur et une idée comment la contourner?

J'ai eu cette erreur en utilisant Java et postgresql en faisant une insertion sur une table. Je vais illustrer comment vous pouvez reproduire cette erreur:

org.postgresql.util.PSQLException: ERROR: 
current transaction is aborted, commands ignored until end of transaction block

Résumé:

La raison pour laquelle vous obtenez cette erreur est que vous avez entré une transaction et que l'une de vos requêtes SQL a échoué, que vous avez englouti cet échec et l'avez ignoré. Mais cela ne suffisait pas, ALORS vous avez utilisé cette même connexion, en utilisant la MÊME TRANSACTION pour exécuter une autre requête. L'exception est levée sur la deuxième requête correctement formée car vous utilisez une transaction interrompue pour effectuer un travail supplémentaire. Postgresql par défaut vous empêche de faire cela.

J'utilise: 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".

Mon pilote postgresql est: postgresql-9.2-1000.jdbc4.jar

En utilisant la version java: Java 1.7

Voici l'instruction de création de table pour illustrer l'exception:

CREATE TABLE moobar
(
    myval   INT
);

Le programme Java provoque l'erreur:

public void postgresql_insert()
{
    try  
    {
        connection.setAutoCommit(false);  //start of transaction.

        Statement statement = connection.createStatement();

        System.out.println("start doing statement.execute");

        statement.execute(
                "insert into moobar values(" +
                "'this sql statement fails, and it " +
                "is gobbled up by the catch, okfine'); ");

        //The above line throws an exception because we try to cram
        //A string into an Int.  I Expect this, what happens is we gobble 
        //the Exception and ignore it like nothing is wrong.
        //But remember, we are in a TRANSACTION!  so keep reading.

        System.out.println("statement.execute done");

        statement.close();

    }
    catch (SQLException sqle)
    {
        System.out.println("keep on truckin, keep using " +
                "the last connection because what could go wrong?");
    }

    try{
        Statement statement = connection.createStatement();

        statement.executeQuery("select * from moobar");

        //This SQL is correctly formed, yet it throws the 
        //'transaction is aborted' SQL Exception, why?  Because:
        //A.  you were in a transaction.
        //B.  You ran a sql statement that failed.
        //C.  You didn't do a rollback or commit on the affected connection.

    }
    catch (SQLException sqle)
    {
        sqle.printStackTrace();
    }   

}

Le code ci-dessus produit cette sortie pour moi:

start doing statement.execute

keep on truckin, keep using the last connection because what could go wrong?

org.postgresql.util.PSQLException: 
  ERROR: current transaction is aborted, commands ignored until 
  end of transaction block

Solutions de contournement:

Vous avez quelques options:

1. Solution la plus simple: ne participez pas à une transaction. Réglez le connection.setAutoCommit(false);sur connection.setAutoCommit(true);. Cela fonctionne car le SQL échoué est simplement ignoré en tant qu'instruction SQL échouée. Vous êtes invités à échouer les déclarations SQL autant que vous le souhaitez et postgresql ne vous arrêtera pas.

2. Restez dans une transaction, mais lorsque vous détectez que le premier SQL a échoué, annulez / redémarrez ou validez / redémarrez la transaction. Ensuite, vous pouvez continuer à échouer autant de requêtes SQL sur cette connexion à la base de données que vous le souhaitez.

3. N'attrapez pas et ignorez l'exception qui est levée lorsqu'une instruction SQL échoue. Ensuite, le programme s'arrêtera sur la requête mal formée.

4. Obtenez Oracle à la place, Oracle ne lève pas d'exception lorsque vous échouez une requête sur une connexion au sein d'une transaction et continuez à utiliser cette connexion.

Dans la défense de la décision de postgresql de faire les choses de cette façon ... Oracle a vous fait doux dans la location du milieu , vous faites des choses stupides et avec vue sur elle.

Vérifiez la sortie avant l'instruction qui a provoqué current transaction is aborted. Cela signifie généralement que la base de données a levé une exception que votre code avait ignorée et s'attend maintenant à ce que les prochaines requêtes renvoient des données.

Vous avez donc maintenant une incompatibilité d'état entre votre application, qui considère que tout va bien, et la base de données, qui vous oblige à annuler et redémarrer votre transaction depuis le début.

Vous devez intercepter toutes les exceptions et les transactions d'annulation dans de tels cas.

Voici un problème similaire.

Je pense que la meilleure solution est d'utiliser java.sql.Savepoint.

Avant d'exécuter une requête qui peut lever SQLException, utilisez la méthode Connection.setSavepoint () et si une exception sera lancée, vous ne restaurez que sur ce point de sauvegarde et non sur toutes les transactions.

Exemple de code:

Connection conn = null;
Savepoint savepoint = null;
try {
    conn = getConnection();
    savepoint = conn.setSavepoint();
    //execute some query
} catch(SQLException e) {
    if(conn != null && savepoint != null) {
        conn.rollback(savepoint);
    }
} finally {
   if(conn != null) {
      try {
          conn.close();
      } catch(SQLException e) {}

   }
}

Des travaux ont été effectués sur le pilote JDBC postgresql, liés à ce comportement:
voir https://github.com/pgjdbc/pgjdbc/pull/477

C'est désormais possible, en définissant

autosave = toujours

Dans Ruby on Rails PG, j'avais créé une migration, migré ma base de données, mais oublié de redémarrer mon serveur de développement. J'ai redémarré mon serveur et cela a fonctionné.

La raison de cette erreur est qu'il existe une autre base de données avant que la mauvaise opération ne conduise à l'opération de base de données en cours ne peut pas être effectuée （J'utilise Google Traduction pour traduire mon chinois en anglais）

Le problème a été résolu dans Infinispan 5.1.5.CR1: ISPN -2023

Vous devez revenir en arrière. Le pilote JDBC Postgres est assez mauvais. Mais si vous souhaitez conserver votre transaction et simplement annuler cette erreur, vous pouvez utiliser des points de sauvegarde:

try {
_stmt = connection.createStatement();
_savePoint = connection.setSavepoint("sp01");
_result = _stmt.executeUpdate(sentence) > 0;
} catch (Exception e){
 if (_savePoint!=null){
 connection.rollback(_savePoint);
}
}

En savoir plus ici:

http://www.postgresql.org/docs/8.1/static/sql-savepoint.html

J'ai eu le même problème mais j'ai ensuite réalisé qu'il y avait une table avec le même nom dans la base de données. Après avoir supprimé cela, j'ai pu importer le fichier.

C'est un comportement très étrange de PostgreSQL, il n'est même pas "conforme à la philosophie PostgreSQL de forcer l'utilisateur à tout rendre explicite" - car l'exception a été interceptée et ignorée explicitement. Donc même cette défense ne tient pas. Oracle dans ce cas se comporte beaucoup plus convivial et (comme pour moi) correctement - il laisse le choix au développeur.

Cela peut se produire si vous manquez d'espace disque sur le volume.

Je rencontre juste la même erreur. J'ai pu déterminer la cause première en activant le log_statement et le log_min_error_statement dans mon PostgreSQL local.

Je Visée cette

J'utilise JDBI avec Postgres et j'ai rencontré le même problème, c'est-à-dire qu'après une violation d'une contrainte d'une déclaration de transaction précédente, les instructions suivantes échoueraient (mais après avoir attendu un moment, disons 20-30 secondes, le problème disparaît ).

Après quelques recherches, j'ai trouvé que le problème était que je faisais une transaction "manuellement" dans mon JDBI, c'est-à-dire que j'ai entouré mes déclarations avec BEGIN; ... COMMIT; et il s'avère que c'est le coupable!

Dans JDBI v2, je peux simplement ajouter l'annotation @Transaction, et les instructions dans @SqlQuery ou @SqlUpdate seront exécutées en tant que transaction, et le problème mentionné ci-dessus ne se produit plus!

Dans mon cas, j'obtenais cette erreur car mon fichier était corrompu. En itérant les enregistrements de fichiers, cela me donnait la même erreur.

Peut-être que dans le futur cela aidera n'importe qui. C'est la seule raison de publier cette réponse.

J'utilise le ressort avec @Transactionalannotation, et j'attrape l'exception et pour quelques exceptions, je réessayerai 3 fois.

Pour posgresql, en cas d'exception, vous ne pouvez plus utiliser la même connexion pour valider. Vous devez d'abord annuler.

Dans mon cas, j'utilise DatasourceUtilspour obtenir la connexion actuelle et appeler connection.rollback()manuellement. Et l'appel à la méthode recruive pour réessayer.

Je travaillais avec Spring Boot jpa et je l'ai corrigé en implémentant @EnableTransactionManagement

Le fichier joint peut vous aider.

Je travaillais avec Spring Boot jpa et je l'ai corrigé en implémentant @EnableTransactionManagement

Le fichier joint peut vous aider.

Essaye ça COMMIT;

Je lance cela dans pgadmin4. Cela peut aider. Cela a à voir avec l'arrêt prématuré de la commande précédente

Modifiez le niveau d'isolement de lecture répétable à lecture validée.

Définissez conn.setAutoCommit (false) sur conn.setAutoCommit (true)

Validez les transactions avant d'en lancer une nouvelle.