Добрый день.
скажите пожалуйста есть у кого-то клас/пример лучше живой код организации работы между базой даных и веб сервером(Tomcat,JSP,Struts).

Мой клас не подходит, вылетает на ошибке Too many connections to server(web server!!!)....
Data source rejected establishment of connection, message from server: "Too many connections"




Пример использования


Это сообщение отредактировал(а) DEMOVERSION - 21.3.2006, 19:46

Уменьши у пула максимальное количество соединений, или наоборот у сервера увеличь его.

а пример кода использования нормальный?
поможет System.gc(), может это очистит в все что неиспользуеться и просто висит?

Да вообщем, тоже нет. Смотри ты соединение из пула берешь (ScheduleManager:29), но не возвращаешь. А просто закрываешь его. Это не правильно.
Алгоритм работы такой: ты создаешь пул соединений, в этом пуле открываешь соединения (можешь вначале вообще ничего не открывать, а делать это по мере необходимости), когда приложению нужно соединение, оно обращается в пул за ним, работает с ним, закрывает все курсоры и statements, но не само соединение, а затем возвращает соединение в пул, пул при завершении работы сам закрывает все соединения.

В данном случае по-моему не так. Дело в том, что соединение берется у commons-dbcp. Эта самая DBCP возвращает не оригинальное соединение от драйвера, а обертку, которая при вызове connection.close() возвратит соединение в пул. Так что в коде, имхо, все правильно.

А параметры пула можно выставить, например, так:

Здесь setMaxActive() устанавливает максимальное количество активных соединений (выполняющих какие-то запросы), setMaxIdle() - максимальное количество открытых неактивных соединений. В javadoc к классу org.apache.commons.pool.impl.GenericObjectPool описания других параметров пула - http://jakarta.apache.org/commons/pool/api...ObjectPool.html.

Спасибо. Буду пробовать. Мне что-то не нравиться что ScheduleManager имеет static методы и поле. Нормально так оставить?

Вообщем, это типичный синглетон. Подходит ли он по задаче или нет, тебе видней.
Тебе надо чтобы все операции с Schedule проходили через одиное место? Если да, то синглетон хорошо для этого подходит.

Я использую это в Struts Action's. Мне надо доставать расписание для груп. Тут подходит?

Смотрю на это и тупо не понимаю.

1. Зачем городить свой конекшн пул? Ваш AppServer что не подерживает коннекшн пулы? Tomcat точно держит. http://www.javenue.info/post/10

2. Ну ладно а ваш JDBC драйвер тоже не имеет "родную" имплементацию?

3. Ну хорошо Бог с ним. а зачем сингл тон? статичным его сделайте и все дела...

зачем себе жизнь усложнять?

Честно говоря трудно оценить как ты его используешь. Если у тебя идет интенсивная работа, но время от времени, то лучше создать по экземпляру. Если обращения время от времени, то подойдет и синглетон.
Единственноее но, объект занимает одно соединение к базе (если вызовы происходят редко то лучше запрашивать соединение по мере необходимости). И плюс если будет несколько одновременных вызовов к методам, то будет конфликт из-за того, что они работают через одно соединение. Надо это как-то решить, или синхронизацией или запросом каждый раз нового соединения (второе предпочтительней).

А, например, в Jetty это опциональная фича. А если я не хочу никаких опций, а хочу веб-контейнер в минимальной конфигурации. Не важно по какой причине. Кроме того, пулы соединений, как правило, поддерживают больше параметров пула чем серверы приложений. Хотя в общем случае я бы тоже предпочел пул от сервера приложений, но ведь не все случаи - общие.

Его к этому никто не обязывает. Например, у jdbc-драйвера PostgreSQL пул есть, но соединений он никогда не закрывает, то есть если у него стоит максимум 10 соединений, то он их создаст и будут они висеть пока приложение не закроется. Согласись, это не есть хорошо.

С обычным экземпляром все-таки попроще чем со статическими методами, а принципиальной разницы в общем-то нет.

Проблема в чем преимущества синглетона перед статическими методами, уже обсуждалась.

LSD угу псомтрел диспут. да да. читал такие же обсуждения в разных местах на разных языках и в раное время. безспорно есть случаи когда без синглотонов не обойтись. есть случае когда они дают определнные выигрыш. но я ИМХО предпочитаю там где не нужно не использовать вот и всё.

tux, ну я слабо представляю себе динамическое вэб приложение без базы данных за спиной. все танцы с бубном вокруг коннекшн пула напоминают мне изобретательство велосипеда. Было время когда DataSource не был частью J2EE и тогда все крутились как могли. Но сейчас смасла в этом ноль. Зачем ставить AppServer и не пользоваться предоставляемыми им сервесами?

"Кроме того, пулы соединений, как правило, поддерживают больше параметров пула чем серверы приложений" это я, честно,совсем не понял. серверы приложений предоставляет вам импелменатцию J2EE DataSource. пользуйтесь. возможности этой имплементации даже у таких средненьких серверов как скажем JRun выше крыши. О каких таких загадочных пармерах реч?

Если JDBC драйвер заявляет что он соотвествует спецификации JDBC 3.0 (могу ошибаться в версии стандарта уж простите) то пул там быть должен. Другое дело что он может быть конечно корявым. да. в этом случае я бы скорее попытался найти альтенативный драйвер нежели чем писать пул самостоятельно....

Ребят поймите меня правильно... я когда-то вынужден был писать коннекшн пулл это та еще задача если делать серьезно там масса нюансов например обслуживание таймаутов и т.п. оно вам не надо, уверяю вас

Ну хотя бы затем, что сервер приложений при этом нужно настраивать, причем каждый сервер, на который нужно разворачивать приложение, приходится настраивать по-своему. И, опять-таки, повторюсь, не все веб-контейнеры предоставляют пулы соединений. Кстати, у Tomcat нет своей реализации пула соединений и по дефолту он использует все тот же commons-dbcp, который DEMOVERSION использует явно. Можно прикрутить и другие. И в где там танцы с бубном не пойму. Пять строчек кода и готов пул соединений, который к тому же не зависит от сервера приложений.

Что касается параметров пула соединений. У многих серверов все параметры ограничиваются максимальным и минимальным количеством соединений. У C3P0 таких параметров порядка 30. Не станешь же ты утверждать что 28 из них никогда не нужны.


А я бы использовал какую-нибудь библиотеку пула соединений. Постоянно работаю с PostgreSQL и родной jdbc-драйвер - единственный бесплатный.


Я тоже писал простенький только для кжширования соединений. Зачем писать свой навороченный если готовых решений пруд пруди.

"Ну хотя бы затем, что сервер приложений при этом нужно настраивать, причем каждый сервер, на который нужно разворачивать приложение, приходится настраивать по-своему."

tux, я искренне не понимаю. Cознательно не пользоваться иплементациями конкретного сервера преложений, чтобы их не настраивать и от них не зависеть? А зачем тогда сервер приложений вообще?
По-моему это порочный подход изначально...

Как это не пользовался? В Томкате ведь источник данных настраивал в server.xml примерно таким образом:

А в сервере приложений Orion источник данных настраивается вот так в файле data-sources.xml:

В Томкате чтобы получить источник данных, нужно еще в web.xml веб-приложения описывать ссылку на ресурс (особенности сервиса JNDI таковы), в Orion можно обращаться по прямому имени в дереве JNDI. Как видишь между серверами значительная разница и убежать от этих различий не удастся. Согласен, если разрабатываешь для конкретного сервера приложений это совершенно не проблема, но если заранее не известно куда придется деплоить приложение, то придется предусматривать кой-какие особенности серверов.