Este team de redactores ha pasado mucho tiempo investigando para dar solución a tus búsquedas, te compartimos la respuesta de modo que deseamos que te sea de gran ayuda.
Solución:
Hemos descubierto la causa de este problema. Se explica por la implementación defectuosa de setQueryTimeout() en los últimos controladores JDBC 9.2-100x. Es posible que no suceda si abre/cierra la conexión manualmente, pero muy a menudo sucede con la agrupación de conexiones en su lugar y compromiso automático ajustado a false. En este caso, se debe llamar a setQueryTimeout() con un valor distinto de cero (como ejemplo, usando la anotación Spring Framework @Transactional( timeout = xxx )).
Resulta que, cada vez que se genera una excepción de SQL durante la ejecución de la instrucción, el temporizador de cancelación no se cancela y permanece activo (así es como se implementa). Debido a la agrupación, la conexión posterior no se cierra, sino que se devuelve a la agrupación. Más tarde, cuando se activa el temporizador de cancelación, cancela aleatoriamente la consulta actualmente asociada con la conexión con la que se creó este temporizador. En este momento, es una consulta totalmente diferente la que explica el efecto de aleatoriedad.
La solución sugerida es renunciar a setQueryTimeout() y usar la configuración de PostgreSQL en su lugar (statement_timeout). No proporciona el mismo nivel de flexibilidad, pero al menos siempre funciona.
Esto supone que el error de condición de carrera en el archivo jar jdbc para postgresql es responsable del error anterior.
Solución 1, actualice la conexión a la base de datos periódicamente
Una solución consiste en cerrar la conexión a la base de datos y crear una nueva conexión a la base de datos periódicamente. Después de cada pocos miles de instrucciones SQL, simplemente cierre la conexión y vuelva a crearla. Entonces, por alguna razón, este error ya no se produce.
Solución alternativa 2, active el registro
Si activa el registro en el nivel del controlador JDBC cuando está configurando el controlador, en algunas situaciones se neutraliza el problema de la condición de carrera:
Class.forName("org.postgresql.Driver");
org.postgresql.Driver.setLogLevel(org.postgresql.Driver.DEBUG);
Solución 3, detecte la excepción y reinicie la conexión
También puede intentar capturar la excepción específica, reinicializar la conexión e intentar la consulta nuevamente.
Solución 4, espere hasta que aparezca el jar postgresql jdbc con una corrección de errores
Creo que el problema puede estar asociado con la velocidad de mi disco duro SSD. Si recibe este error, publique cómo reproducirlo de manera consistente aquí, hay desarrolladores muy interesados en eliminar este error.
Si recibe este error sin usar transacciones
El usuario ha solicitado la cancelación del estado de cuenta. La declaración está haciendo exactamente lo que se le dice que haga. La pregunta es, ¿quién pidió que se cancelara esta declaración?
Mire cada línea en su código que prepara el SQL para su ejecución. Podría tener algún método que se aplique a la declaración que cancela la declaración en algunas circunstancias, como esta:
statement = conn.createStatement();
conn.setAutoCommit(true);
statement.setQueryTimeout(25);
my_insert_statement.setString(1, "moobars");
my_insert_statement.executeUpdate();
statement.close();
En mi caso, lo que sucedió fue que había establecido el tiempo de espera de la consulta en 25 segundos, y cuando la inserción tardó más que eso. Pasó la excepción de ‘cancelación de la declaración debido a la solicitud del usuario’.
Si recibe este error al usar transacciones:
Si recibe esta excepción, verifique dos veces todo su código que realiza transacciones SQL.
Si tiene una consulta que está en una transacción y olvida confirmar, y luego usa esa conexión para hacer otra cosa en la que opera como si no estuviera en una transacción, podría haber un comportamiento indefinido que produzca esta excepción.
Asegúrese de que todo el código que realiza una transacción se limpie después de sí mismo. Asegúrese de que la transacción comience, se haya realizado el trabajo, se haya realizado más trabajo y la transacción se revierta o confirme, luego asegúrese de que la conexión se deje en el autocommit=true Expresar.
Si este es su problema, entonces la Excepción no se lanza donde se olvidó de limpiar después de usted mismo, sucede en algún lugar mucho después de que no pudo limpiar después de una transacción, lo que hace que esta sea una excepción difícil de rastrear. Actualizar la conexión (cerrarla y obtener una nueva) lo aclarará.