Влияние настроек C3P0 на метод Thread.sleep () - PullRequest
1 голос
/ 06 ноября 2019

Я установил настройки c3PO следующим образом

hibernate.c3p0.min_size = "20";
hibernate.c3p0.max_size = "30";
hibernate.c3p0.maxConnectionAge = "10";
hibernate.c3p0.timeout = "15";

Тогда у меня есть мой код следующим образом

@Transactional
void m1(){
    for(int i = 0; i<10; i++){
        fetch(); // fetches db entry
        Thread.sleep(20000);
        update(); // updates db entries
     }
}

Здесь я заставил поток спать в течение 20 секунд (> maxConnectionAge иТайм-аут). Затем код успешно выполняется без соединения с БД . Почему это так?

Может ли кто-нибудь помочь мне понять

  1. Выполняется ли только один поток для транзакции? Если да, то почему мы не получаем никаких проблем с тайм-аутом дБ?

  2. Какие все параметры C3P0 / параметры БД приводят к тому, что дБ соединение закрыто? . Кроме того, @Transactional играет роль в этой проблеме?

1 Ответ

1 голос
/ 07 ноября 2019

Когда соединение проверяется, обычно c3p0 не связывается с ним. Это в руках клиентов. Вы можете спать миллион лет, c3p0 не будет close(), что Connection, пока он не будет возвращен в управление c3p0.

Из этого правила есть одно важное исключение, что c3p0 не связывается с провереннымout Connection - настройка c3p0 unreturnedConnectionTimeout . То есть предназначено специально для обхода и / или отладки клиентских приложений с утечками Connection. Возможно, это именно тот параметр, который вы ищете.

В общем, c3p0 управляет жизненным циклом физического Connections в соответствии с вашими настройками. maxConnectionAge, maxIdleTime, maxIdleTimeExcessConnections, настройки и результаты тестирования подключений могут привести к тому, что физические подключения будут close() ed , когда они находятся в ведении пула, а не клиента . Клиенты несут ответственность за close() проверки подключений, которые они проверяют (что фактически не разрушает физический Connection, а вместо этого возвращает его в пул).

...