Wir haben die Ursache dieses Problems herausgefunden. Dies wird durch die fehlerhafte Implementierung von setQueryTimeout() in den neuesten JDBC-Treibern 9.2-100x erklärt. Es passiert möglicherweise nicht, wenn Sie die Verbindung manuell öffnen / schließen, aber es passiert sehr oft mit Verbindungspooling und Autocommit auf false setzen . In diesem Fall sollte setQueryTimeout() mit einem Wert ungleich Null aufgerufen werden (als Beispiel mit der Annotation @Transactional( timeout =xxx ) des Spring-Frameworks).
Es stellt sich heraus, dass der Abbruch-Timer nicht abgebrochen wurde und am Leben bleibt (so wird er implementiert), wenn während der Ausführung der Anweisung eine SQL-Ausnahme ausgelöst wird. Aufgrund des Poolings wird die Verbindung dahinter nicht geschlossen, sondern an den Pool zurückgegeben. Später, wenn der Abbruch-Timer ausgelöst wird, bricht er zufällig die Abfrage ab, die derzeit der Verbindung zugeordnet ist, mit der dieser Timer erstellt wurde. Im Moment ist es eine ganz andere Abfrage, die den Zufallseffekt erklärt.
Die vorgeschlagene Problemumgehung besteht darin, setQueryTimeout() aufzugeben und stattdessen die PostgreSQL-Konfiguration zu verwenden (statement_timeout). Es bietet nicht das gleiche Maß an Flexibilität, funktioniert aber zumindest immer.
