We hebben de oorzaak van dit probleem gevonden. Het wordt verklaard door de implementatie van setQueryTimeout() met fouten in de nieuwste JDBC-stuurprogramma's 9.2-100x. Het gebeurt misschien niet als u de verbinding handmatig opent / sluit, maar gebeurt heel vaak met pooling van verbindingen en autocommit ingesteld op false . In dit geval moet setQueryTimeout() worden aangeroepen met een waarde die niet nul is (bijvoorbeeld met Spring-framework @Transactional( timeout =xxx ) annotatie).
Het blijkt dat telkens wanneer SQL-uitzondering wordt gegenereerd tijdens de uitvoering van de instructie, de annuleringstimer niet is geannuleerd en blijft bestaan (zo is het geïmplementeerd). Vanwege pooling wordt de achterliggende verbinding niet gesloten maar teruggestuurd naar de pool. Later, wanneer de annuleringstimer wordt geactiveerd, wordt de query die momenteel is gekoppeld aan de verbinding waarmee deze timer is gemaakt, willekeurig geannuleerd. Op dit moment is het een totaal andere vraag die het willekeurig effect verklaart.
De voorgestelde oplossing is om setQueryTimeout() op te geven en in plaats daarvan PostgreSQL-configuratie te gebruiken (statement_timeout). Het biedt niet hetzelfde niveau van flexibiliteit, maar werkt in ieder geval altijd.