Здравствуйте!
Использую в приложении Hibernate и пул c3p0, но есть некоторые сомнения как лучше работать с объектоми Session, а именно - нужно ли вызывать метод close() у него? Вроде бы где-то читал что при использовании пула этого делать не надо, но "меня терзают смутные сомнения" по этому поводу..... Поделитесь опытом плиз....

Ссылку в студию, лично найду вредителя. Закрывать сессию надо всегда.

   и ты не первый..    вот здесь Tony мучали похожие сомнения

Maksym,  спасибо огромное за ссылку. Только вот что-то не получается у меня нормально разрулить дело с коннекшнами..... Они не закрываются... а мне необходимо чтобы сервер выдерживал как минимум 50 одновременных соединений. А сейчас он 10 не может разрулить ((( Вот конфигурация пула:


И вообще как должен выглядеть "жизненный цикл работы с сессиями"? У меня сейчас происходит все так:

однако нетстат показывает что коннекты висят на базу..... да и потоки тестовые зависают.....   что делать ???  


Это сообщение отредактировал(а) skhilkov - 15.9.2007, 19:24

и не у меня одного такая проблема..... однако решения однозначного не нашел.....

Это сообщение отредактировал(а) skhilkov - 15.9.2007, 19:22

В чем симптомы того, что сервер не выдерживает 50 соединений? Сервер падает? Не понятно совершенно.


Закрывать соединение нет необходимости, метод close() у соединения вызывается при закрытии сессии.

А теперь о том, как работают пулы соединений и зачем они нужны. Открытие соединения к базе - операция не самая быстрая и если при выполнении каждого запроса открывать соединение, это сильно скажется на производительности, поэтому это сразу не вариант. Так вот, в реальных системах стараются избавится от повторяющихся операций открытия и закрытия. Класс соединения, который реализован драйвером JDBC, естественно, реально закрывает соединение. Но пул реализует надстройку над этим классом, которая переопределяет метод close(), не закрывающий соединение, а помещающий его в очередь свободных соединений, то есть соединение реально не закрывается, а просто освобождается для дальнейшего использования. Вот эти открытые соединения ты, видимо, и наблюдаешь и это совершенно правильно, так должно быть. Это дает возможность многократно повторно использовать одно и то же соединение, не тратя время на пересоединение. Кроме того, поскольку эти соединения могут использоваться многими клиентами, они используются более эффективно.

Теперь о настройке пула. Параметры, которые ты приводишь, означают следующее:

• hibernate.c3p0.min_size - это минимальный размер пула. То есть при старте приложения сразу создается 10 открытых соединений
• hibernate.c3p0.max_size - максимальный размер пула. То есть больше 25-ти в твоем случае C3P0 создавать не будет. А если пользователь запросит новое 26-ое соединение, поставит его в состояние ожидания. Это запрещает бесконтрольное неограниченное создание соединения
• hibernate.c3p0.timeout - это время в секундах, в течение которого клиент будет ожидать соединение если нет свободного. После окончания интервала времени выкинется исключение

Итого, какие можно сделать выводы. Поскольку из твоих слов не понятно в каком месте система падает, могу только посоветовать поиграться с параметрами min_size и max_size. Кроме того, могу предположить, что у базы данных есть ограничение на количество открытых соединений и оно <=10. В общем поисследуй в этом направлении. То, что соединения у тебя висят открытыми - совершенно правильно, они специально не закрываются, избавиться от этого легко - убрать пул, только это будет неправильно, а в Hibernate от этого вовсе не избавиться - у Hibernate есть встроенный пул, который он используется по дефолту. 

Это сообщение отредактировал(а) tux - 15.9.2007, 23:11

tux,  спасибо за разъяснение.

Значит я написал небольшой тестик - у меня есть 10 потоков, которые запускаются одновременно и должны кинуть на сервер по 2 запроса. Так вот, по одному запросу они успевают сделать, а дальше виснут.... Какие мне параметры надо прописать чтобы соединения освобождались сразу же, а не висли вот так...... ????
ЗЫ При этом нетстат показывает 25 открытых соединений к базе....

Это сообщение отредактировал(а) skhilkov - 16.9.2007, 10:50

А ты не мог бы привести код теста, хочу у себя попробовать. Какая-то совершенно неправильная ситуация.

Добавлено через 1 минуту и 59 секунд
И еще СУБД и версию драйвера было бы неплохо знать. На первый взгляд все делается правильно.

tux, 
там достаточно много кода. Если хочешь и есть время - скину на мыло. Принцип таков: 
Подключается клиент, затем он начинает запрашивать разную инфу. Причем эта инфа хранится в 40 таблицах, соответственно для выборки каждого определенного вида информации открывается сессия. Мне кажется что пул очень плохо закрывает соединения, потому как сейчас, например, при последнем обращении к серверу около 2-х часов назад нетстат показывает 40 открытых соединений к базе..... статистика не радует    
Может мне тогда следует для каждого клиента получать коннекшн и его сохранять в сессии.... Тогда, спрашивается, зачем нужен пул???

ЗЫ сервер Tomcat 5.5 база MySQL 4.1 JDBC Driver - mysql-connector-java-5.0.4

Это сообщение отредактировал(а) skhilkov - 20.9.2007, 16:05

в статистике нетстата половина соединений ожидает закрытия.... почему не закрываются если я проставил время жизни маленькое???

tcp6       0      0 ::ffff:10.0.0.1%1:60514 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       1      0 ::ffff:10.0.0.1%1:60744 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       1      0 ::ffff:10.0.0.1%1:60918 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       0      0 ::ffff:10.0.0.1%1:59553 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       0      0 ::ffff:10.0.0.1%1:60132 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       1      0 ::ffff:10.0.0.1%1:60389 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       0      0 ::ffff:10.0.0.1%1:59062 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       1      0 ::ffff:10.0.0.1%1:59372 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       0      0 ::ffff:10.0.0.1%1:57433 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       1      0 ::ffff:10.0.0.1%1:57606 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       0      0 ::ffff:10.0.0.1%1:57902 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       0      0 ::ffff:10.0.0.1%1:57939 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       1      0 ::ffff:10.0.0.1%1:58077 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       1      0 ::ffff:10.0.0.1%1:52873 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       1      0 ::ffff:10.0.0.1%1:52886 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       1      0 ::ffff:10.0.0.1%1:51266 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       0      0 ::ffff:10.0.0.1%1:51280 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       1      0 ::ffff:10.0.0.1%1:51923 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       1      0 ::ffff:10.0.0.1%1:51005 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       0      0 ::ffff:10.0.0.1%1:49160 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       1      0 ::ffff:10.0.0.1%1:49684 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       0      0 ::ffff:10.0.0.1%1:50133 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       0      0 ::ffff:10.0.0.1%1:56483 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       1      0 ::ffff:10.0.0.1%1:57132 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       0      0 ::ffff:10.0.0.1%1:55313 ::ffff:10.0.0.3%80:3310 ESTABLISHED
tcp6       0      0 ::ffff:10.0.0.1%1:55688 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       0      0 ::ffff:10.0.0.1%1:55791 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       1      0 ::ffff:10.0.0.1%1:55814 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       1      0 ::ffff:10.0.0.1%1:56245 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       0      0 ::ffff:10.0.0.1%1:56256 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       1      0 ::ffff:10.0.0.1%1:53593 ::ffff:10.0.0.3%80:3310 CLOSE_WAIT 
tcp6       1      0 ::ffff:10.0.0.1%1:44707 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       0      0 ::ffff:10.0.0.1%1:43229 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       1      0 ::ffff:10.0.0.1%1:43839 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       1      0 ::ffff:10.0.0.1%1:40995 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       0      0 ::ffff:10.0.0.1%1:41155 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       0      0 ::ffff:10.0.0.1%1:41979 ::ffff:10.0.0.3%80:3310 ESTABLISHED
tcp6       1      0 ::ffff:10.0.0.1%1:48194 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       0      0 ::ffff:10.0.0.1%1:48924 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       0      0 ::ffff:10.0.0.1%1:46119 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       0      0 ::ffff:10.0.0.1%1:36119 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       1      0 ::ffff:10.0.0.1%1:34946 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       0      0 ::ffff:10.0.0.1%1:34201 ::ffff:10.0.0.3%80:3310 ESTABLISHED
tcp6       0      0 ::ffff:10.0.0.1%1:39143 ::ffff:10.0.0.3%81:3310 ESTABLISHED
tcp6       1      0 ::ffff:10.0.0.1%1:37142 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 
tcp6       1      0 ::ffff:10.0.0.1%1:37426 ::ffff:10.0.0.3%81:3310 CLOSE_WAIT 

А кто его знает? Может в драйвере что-то нужное C3P0 не реализовано. Попробуй на DBCP поменять пул. Или код все-таки пришли на попробовать. 

tux, 
дружище, +1!!!! Прямо в цель!!!!