Разбрахме причината за този проблем. Това се обяснява с бъговата реализация на setQueryTimeout() в най-новите JDBC драйвери 9.2-100x. Това може да не се случи, ако отворите/затворите връзката ръчно, но много често се случва с пулиране на връзки на място и автоматично ангажиране зададено на false . В този случай setQueryTimeout() трябва да се извика с различна от нула стойност (като пример, използвайки пролетна рамка @Transactional( timeout =xxx) анотация).
Оказва се, че всеки път, когато се повдигне SQL изключение по време на изпълнението на израза, таймерът за анулиране не е отменен и остава активен (така е реализиран). Поради обединяването задната връзка не се затваря, а се връща в пула. По-късно, когато таймерът за анулиране се задейства, той произволно отменя заявката, свързана в момента с връзката, с която е създаден този таймер. В този момент това е напълно различна заявка, която обяснява ефекта на случайността.
Предложеното заобиколно решение е да се откажете от setQueryTimeout() и вместо това да използвате конфигурация на PostgreSQL (statement_timeout). Не осигурява същото ниво на гъвкавост, но поне винаги работи.
