Estoy viendo el siguiente (trunca) stacktrace en el servidor.archivo de registro 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

La inspección de la Postgres archivo de registro revela las siguientes declaraciones:

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

Estoy usando el Infinispan se entregan con JBoss 7.1.1 Final, que es 5.1.2.Final.

Así que esto es lo que creo que está sucediendo:

  • Infinispan, intenta ejecutar el SELECT count(*)... declaración en fin a ver si hay registros en la ISPN_MIXED_BINARY_TABLE_configCache;
  • Postgres, por alguna razón, no le gusta esta declaración.
  • Infinispan ignora esto y arados adelante con la CREATE TABLE declaración.
  • Postgres barfs porque todavía piensa que es la misma transacción, que Infinispan no ha logrado revertir, y esta transacción es perjudicados desde el primer SELECT count(*)... declaración.

Lo que hace este error significa y alguna idea de cómo solucionar el problema?

  • Sólo si usted vino aquí como yo buscando el anterior PSQLException: current transaction is aborted... (25P02) y tal vez también JPA o Hibernate. Finalmente fue debido a la nuestra (bueno!) Logback el uso de la fed con un toString()-sobrecargado de objetos DAO que provocó el error y fue muy bien tragado (pero accidentalmente la desapercibido por mí): log.info( "bla bla: {}", obj ) producidos bla bla: [FAILED toString()]. el cambio a log.info( "bla bla: {}", String.valueOf( obj ) hizo null-seguro, pero no tragar y dejando así abierta la transacción fracasar en una relación de consulta.
InformationsquelleAutor Jimidy | 2012-05-01

15 Comentarios

  1. 173

    Tengo este error utilizando Java y postgresql hacer un insert en una tabla. Voy a ilustrar cómo puede reproducir este error:

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

    Resumen:

    La razón de que este error es porque han entrado en una transacción y una de las Consultas de SQL error y se tragó hasta que el fracaso y la ignoró. Pero eso no era suficiente, ENTONCES usted utiliza la misma conexión, utilizando la MISMA TRANSACCIÓN para ejecutar otra consulta. La excepción se tira en el segundo, se ha formado correctamente la consulta porque está utilizando una fractura de transacción para hacer el trabajo adicional. Postgresql por defecto te deja de hacer esto.

    Estoy usando: 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".

    Mi postgresql conductor: postgresql-9.2-1000.jdbc4.jar

    El uso de la versión de java: Java 1.7

    Aquí está la tabla de la instrucción create para ilustrar la Excepción:

    CREATE TABLE moobar
    (
    myval   INT
    );

    Programa de Java que causa el error:

    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();
    }   
    }

    El código anterior produce la siguiente salida para mí:

    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

    Soluciones:

    Usted tiene un par de opciones:

    1. Solución más sencilla: no estar en una transacción. Establecer el connection.setAutoCommit(false); a connection.setAutoCommit(true);. Funciona porque entonces el error de SQL es simplemente ignorado como un error en la instrucción sql. Usted es bienvenido a fallar instrucciones sql todo lo que quieres y postgresql no te detenga.

    2. De estancia en una transacción, pero cuando se detecta que la primera sql ha fallado, ya sea la reversión o re-iniciar o commit/reiniciar la transacción. Entonces usted puede seguir fallando, como muchas consultas sql en que la conexión de base de datos como desee.

    3. No de capturas y de ignorar la Excepción que se produce cuando una instrucción sql falla. A continuación, el programa se detendrá en la consulta malformada.

    4. Obtener Oracle en su lugar, Oracle no lanzar una excepción cuando no una consulta en una conexión dentro de una transacción, y seguir usando esa conexión.

    En defensa de postgresql la decisión de hacer las cosas de esta manera… Oracle fue haciendo suave en el medio que permite hacer cosas tontas y con vistas a ella.

    • Lol @ la Opción 4… me había hecho un poco de desarrollo en Oracle, y recientemente comenzó a utilizar Postgres… es realmente molesto que Postgres no esta, y ahora tenemos que estar muy reescribir una gran mayoría de nuestro programa que se está portando de Oracle a Postgresql. ¿Por qué no hay una opción como la primera para que se comporte como Oracle, pero sin el auto-commit?
    • Después de algunos ensayos, que Opción 2 es lo más cerca que puede llegar a Oracle comportamiento. Si usted necesita para emitir varias actualizaciones, y un fracaso no debe dejar de posteriores actualizaciones, simplemente llame a rollback() en el Connection cuando un SQLException es capturado. [de todos Modos me di cuenta de esto está en línea con el PostgreSQL filosofía de obligar al usuario a hacer todo lo explícito, mientras que Oracle tiene la filosofía de que implícitamente cuidar de un montón de cosas.]
    • Es allí una manera de comprobar el objeto de Conexión (en Java) para ver si una transacción ha fallado?
    • Opción 2 contiene imposible rama or commit/restart the transaction. Como puedo ver que no hay forma de cometer después de excepción. Cuando yo intente cometer PostgreSQL hacer rollback
    • Puedo confirmar que el problema planteado por @turbanoff. Esto también puede ser reproducido directamente con psql. (1) iniciar una transacción, (2) el problema de algunas declaraciones válidas, (3) emitir una instrucción no válida, (4) cometer –> psql va a deshacer en lugar de comprometerse.
    • postgresql.org/message-id/op.ur57x9ue33x80h%40insanity.lain.pl una interesante discusión de este tema. Si este problema es provocado por una violación de la restricción, los desarrolladores de PostgreSQL recomienda la comprobación de un conflicto antes de tiempo (consulta antes de la update/insert) o el uso de savepoints para volver al punto de antes de la update/insert. Consulte stackoverflow.com/a/28640557/14731 de código de ejemplo.

  2. 21

    Compruebe la salida antes de de la instrucción que causó current transaction is aborted. Normalmente, esto significa que la base de datos lanzó una excepción que el código había ignorado y ahora esperando el próximo consultas para obtener algunos datos.

    Así que ahora tiene un estado de desajuste entre su aplicación, que considera que las cosas están bien, y la base de datos, que requiere de deshacer y volver a iniciar la transacción desde el principio.

    Debe capturar todas las excepciones y deshacer transacciones en tales casos.

    He aquí un problema similar.

    • Eso es genial, excepto que en este caso sería Infinispan, una 3ra parte de la biblioteca, haciendo hablar a Postgres, y no es mi código.
    • Así, la situación sigue siendo la misma transacción tiene que revertirse. Tal vez comprobar si hay una nueva versión de la biblioteca que desea utilizar o aumento de la cuestión dentro de su sistema de seguimiento de fallos. Si usted encontrará exactamente SQL que provocó el problema, tendrás algún campo para eliminar el problema utilizando PostgreSQL extensibilidad.
    • Parece que se ha confirmado mis sospechas – voy a mirar en el Infinispan 5.1.2 fuente de ahora.
    • Para ser justos, en el TableManipulation de clase, hay un try-catch en el intento de ejecutar select count(*)…. Quizás el Postgres controlador no está lanzando una de las excepciones esperadas. Voy a conectar un depurador de JBoss para tratar de averiguar más.
    • El Infinispan código en cuestión, se sugirió que en este error: issues.jboss.org/browse/… he adjuntado un depurador para que se ejecute en un live JBoss 7.1.1 instancia y Postgres es lanzar excepciones en los lugares correctos. Tal vez es el JdbcUtil.safeClose() declaraciones que no están haciendo su trabajo. Voy a subir con Infinispan.
    • La levantó con Infinispan aquí: issues.jboss.org/browse/ISPN-2023

  3. 8

    Creo que la mejor solución es el uso de java.sql.Punto de retorno.

    Antes de ejecutar una consulta, lo que puede lanzar SQLException utilice el método de Conexión.setSavepoint (), y si la excepción se tiran sólo volver a este punto de retorno no deshacer todas las transacciones.

    Ejemplo de código:

    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) {}
    }
    }
    • Yo accidentalmente votada abajo de alguna manera, apenas lo notó. No fue intencional, no me puedo deshacer a menos que la respuesta es editado.
    • El punto de retorno manera es la verdadera solución. A mi me funciona también en el entorno de PHP, Doctrine2 y Postgres (9.5). Gracias
  4. 5

    En Ruby on Rails, PG, había creado una migración, migrado mi DB, pero se olvidó de reiniciar mi servidor de desarrollo. He reiniciado mi servidor y funcionó.

    • Ese fue mi caso. Pensé que debía ser algo estúpido, porque yo en realidad no tratan de hacer algo tan complicado.
  5. 3

    La razón de este error es que hay otra base de datos antes de que el mal funcionamiento llevado a la actual base de datos de la operación no puede llevarse a cabo(yo uso el traductor de google para traducir mi chino al inglés)

  6. 3

    Ha habido algunos trabajos realizados sobre el Controlador JDBC de postgresql, en relación con este comportamiento:

    ver https://github.com/pgjdbc/pgjdbc/pull/477

    Ahora es posible, mediante el establecimiento de

    autosave=siempre

    en la conexión (consulte la https://jdbc.postgresql.org/documentation/head/connect.html) para evitar la «corriente de la transacción se aborta’ syndroma.
    Sobrecarga debido a la manipulación de un punto de retorno en torno a la ejecución de la sentencia es muy bajo (ver el enlace de arriba para más detalles).

  7. 2

    Que es necesario deshacer los cambios. El JDBC de Postgresql. driver es bastante malo. Pero si usted quiere mantener su operación, y que acaba de deshacer ese error, puede utilizar savepoints:

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

    Leer más aquí:

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

  8. 1

    Tuve el mismo problema, pero entonces se dio cuenta de que hay una tabla con el mismo nombre en la base de datos. Después de la eliminación de que yo era capaz de importar el archivo.

  9. 0

    Esto es muy extraño el comportamiento de PostgreSQL, que no es ni siquiera «en línea con el PostgreSQL filosofía de obligar al usuario a hacer todo lo explícito» – como la excepción fue capturado y se omite explícitamente. Así que incluso esta defensa no se sostiene. Oracle, en este caso se comporta mucho más amigable para el usuario y (para mí) correctamente – se deja una opción para el desarrollador.

  10. 0

    Esto puede suceder si usted está fuera de espacio en disco en el volumen.

    • Me doy cuenta de que esta no es la causa más común, pero este fue el caso en un servidor que me pidieron para solucionar problemas. Así que creo que esta debería ser considerada como una causa potencial.
  11. 0

    Estoy usando JDBI con Postgres, y se encontró con el mismo problema, es decir, después de una violación de alguna de restricción de una declaración de la transacción anterior, las posteriores declaraciones de fallar (pero después de esperar un rato, digamos de 20 a 30 segundos, el problema desaparece).

    Después de algunas investigaciones, encontré que el problema era que yo estaba haciendo la transacción «manualmente» en mi JDBI, es decir, rodeé mis declaraciones con COMENZAR;…COMETER; y resulta ser el culpable!

    En JDBI v2, sólo puedo añadir @Transacción de anotación, y de las declaraciones dentro de @SqlQuery o @SqlUpdate se ejecutará como una transacción, y el mencionado problema de que no suceda más!

Dejar respuesta

Please enter your comment!
Please enter your name here