Tomcat Jdbc Connection Pool активное соединение

Question

У нас есть spring-boot приложение, которое использует embedded tomcat для развертывания и по умолчанию tomcat-jdbc пул соединений с MySQL бэкэнд без настройки для MySQL или Tomcat.
В приложении есть несколько планировщиков, которые работают в основном в определенное время дня, то есть между последним запуском cron вчера и 1-м выпуском cron сегодня, разрыв составляет более 9 часов. Однако всякий раз, когда cron запускался раньше, он никогда не сталкивался idle проблема с сетевым подключением.

В настоящее время мы видим сообщение об ошибке
The last packet successfully received from the server was XXXXXXXX milliseconds ago. The last packet sent successfully to the server was XXXXXXXY milliseconds ago.

Я всегда могу попробовать использовать testOnBorrow с validateQuery adn / или testWhileIdle и т. Д. Как reqd, чтобы это работало, но...

Я пытаюсь понять жизненный цикл активного соединения в пуле соединений tomcat-jdbc. Согласно документации, значение по умолчанию для wait_timeout для MySQL это 8 часов, тогда как по умолчанию для idle_connection_timeout на Tomcat_jdbc составляет почти 6 секунд.

1. Если значение по умолчанию используется везде, то почему проблема никогда не возникала раньше?
2. Или это то, что соединения в пуле соединений tomcat-jdbc становятся активными каждый раз, когда cron начинает работать и после этого становится свободным?
3. Это какое-то значение имеет состояние приложения с загрузочной пружиной или планировщика?
   
   Любое руководство к правильному ресурсу высоко ценится! Спасибо

Answer 1

Проблема не в конфигурации или настройке. spring-boot приложение использует spring-data lib, которая использует базовый connection pool, Пул обрабатывает соединение (я) согласно реализации пула соединений. Использование @Transactional однако решает, когда основное соединение открыто. Если нет ни одного, указанного в spring-boot приложение реализация по умолчанию spring-data открывает его во время грубых операций; иначе он открывается во время вызова метода в приложении с пометкой @Transactional,

В моем случае это был последний вариант. После открытия соединения выполнялся процесс, не требующий времени для БД, который заставлял соединение бездействовать после открытия и выдавал исключение при его последующем использовании.

Надеюсь, это поможет другим..