Уже несколько раз встречал советы типа "Используй для коннекта к БД connection pool". Объясните плиз, кратенько, с чем его едят, в чем выгода и, если можно, скелетную схему реализации.

Основная идея connection pool состоит в том, что затраты на создание коннекта к базе достаточно ресурсоемкая операция и удобно иметь некоторое количество уже готовых коннектов к базе, которые пул выдает по требованию.

Т.е. идея сделать класс, который внутри себя содержит массив уже открытх коннектов. При запросе коннекта пул отдает свобожный и помечает его как занятый. После того, кака клиент закончил работать с коннектом, он не закрывает его, а отдает обратно пулу.

Если у пула нет свободных коннектов, то можно либо открывать еще конекты, либо просить клиента подождать.

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

Тогда такой вопрос: J2EE сервер - это ведь не то же самое, что веб-сервер? Скажем, Томкат - имеет пул соединений?

И можно еще какую-нибудь ссылочку, чтоб больше не отвлекать

Ну это сильно зависит от сервера. Вот наример для JBoss можно посмотреть Connection Pool Configuration Examples and Driver Notes

Пасиба. Я, правда, с JBoss'ом никогда не работал, но ведь надо когда-то и начинать

Цитата(Lamer @ 18.2.2005, 17:31)

Тогда такой вопрос: J2EE сервер - это ведь не то же самое, что веб-сервер? Скажем, Томкат - имеет пул соединений? И можно еще какую-нибудь ссылочку, чтоб больше не отвлекать

пулл соединений он имеет, как и пул тхреадов.
НО! ты спрашивал про пулл соединений с БД - тут тебе никто не поможет - делай сам. Правда в JDBC для FireBird уже к примеру что-то реализовано.
Но на практике - этот самый пулл коннектов к БД делается за 15-30мин. _свой_ ... так что лучше свой .

Sleepy_PIP

Цитата(Guest @ 19.2.2005, 16:17)

Но на практике - этот самый пулл коннектов к БД делается за 15-30мин. _свой_ ... так что лучше свой

Это если уже умеешь... А если нет - то несколько дней...

Цитата(Guest @ 19.2.2005, 07:17)

Но на практике - этот самый пулл коннектов к БД делается за 15-30мин. _свой_ ... так что лучше свой smile.

Есть хороший принцип - NIH (Not Invented Here). Суть его в том, что в 99,9999% случаев написанная тобой за 15-30 минут примочка будет хуже, чем аналогичная, но написанная специалистами, оттестированная тысячами пользователей.

http://db.apache.org/torque/index.html

Цитата(Domestic @ 19.2.2005, 20:05)

Цитата(Guest @ 19.2.2005, 07:17) Но на практике - этот самый пулл коннектов к БД делается за 15-30мин. _свой_ ... так что лучше свой smile. Есть хороший принцип - NIH (Not Invented Here). Суть его в том, что в 99,9999% случаев написанная тобой за 15-30 минут примочка будет хуже, чем аналогичная, но написанная специалистами, оттестированная тысячами пользователей. http://db.apache.org/torque/index.html

извини, но тогда надо сравнивать время разработки своей примочки с суммой времен - на: 1. поиск чужей примочки+2. освоение чужей примочки+3.тестирование чужей примочки+4. обход багов чужой примочки (хорошо если она с сорцами!).
Так что вопрос для программера - в балансировании между временем разработки своего варианта решения, или временем на применение чъего-то другого решения.
Мое решение (собственное) пережило 2 серевера БД. А вот найти и разобраться с аналогичным за 30 мин. мне не удалось тем более что речь идет и правда о малых трудозатратах.

Как яркий пример могу привести common-net - я взял ее для работы с FTP. и затратил довольно много времени для разбирателвств с нею, и переделки ее под понимание русских букв.
В ведь common-net используют наверняка тысячи пользователей!.
Аналогично повторяется с ADF-Faces - я уже как несколько мес. (вечерами) тестирую эту библиотеку, постоянно нарываясь на баги ... ну и что теперь? Но сесть и писать свою - я не в состоянии ... т.е. вот конкретный пример выбора между суммой времен ... и так везде.
ну разве не так?

Цитата(Guest @ 20.2.2005, 17:25)

Цитата(Domestic @ 19.2.2005, 20:05) Цитата(Guest @ 19.2.2005, ) Но на практике - этот самый пулл коннектов к БД делается за 15-30мин. _свой_ ... так что лучше свой smile. Есть хороший принцип - NIH (Not Invented Here). Суть его в том, что в 99,9999% случаев написанная тобой за 15-30 минут примочка будет хуже, чем аналогичная, но написанная специалистами, оттестированная тысячами пользователей. http://db.apache.org/torque/index.html извини, но тогда надо сравнивать время разработки своей примочки с суммой времен - на: 1. поиск чужей примочки+2. освоение чужей примочки+3.тестирование чужей примочки+4. обход багов чужой примочки (хорошо если она с сорцами!).

ООО! Пардон. не заметил что у меня рецепты сбросились ... Приношу извинений - посл. письмо - от меня ...

Если речь о небольшом приложении и единичной потребности, то да. Но по большому счету я не соглашусь. Ты ведь пользуешь например ArrayList? Самому его легко написать, но если туда попадет баг - потратишь время.
Тот же коннекшн пул - даже простейший вариант означает многопоточность. Сделаешь маленький недосмотр, оттестишь - работает. А в рабочих условиях все накрывается медным тазиком при большом числе коннекшнов. Тут проще потратить 1 день и разобраться с чужим приложениием, чем потом мучаться неделю на выслеживание трудноуловимого бага.

Цитата(Domestic @ 20.2.2005, 19:59)

Если речь о небольшом приложении и единичной потребности, то да. Но по большому счету я не соглашусь. Ты ведь пользуешь например ArrayList? Самому его легко написать, но если туда попадет баг - потратишь время. Тот же коннекшн пул - даже простейший вариант означает многопоточность. Сделаешь маленький недосмотр, оттестишь - работает. А в рабочих условиях все накрывается медным тазиком при большом числе коннекшнов. Тут проще потратить 1 день и разобраться с чужим приложениием, чем потом мучаться неделю на выслеживание трудноуловимого бага.

ну вот в Опен соурс разборки в 1 день - малы. надо как я и писал - найти, разобраться ( и ВЫБРАТЬ!), попатсть на баги и научиться их обходить ... для данной, пприведенной задачи - это не стоит так делать, согласись!

Цитата(Sleepy_PIP @ 20.2.2005, 11:18)

ну вот в Опен соурс разборки в 1 день - малы. надо как я и писал - найти, разобраться ( и ВЫБРАТЬ!), попатсть на баги и научиться их обходить ... для данной, пприведенной задачи - это не стоит так делать, согласись!

Зато, потратив время на Стратс, коммонс и т п, потом легче и проще писать.

Пардон, это опять я вклиниваюсь в беседу умных людей. "Коммонс" - это библиотеки common-net и еще несколько common-что-то, да?

Лучше использовать общепризнанные технологии. Они лучше оттестированны, обеспечивают большую гибкость и универсальность.
Да, тот код который ты напишешь, будет подходить под твои условия лучше, но по мере развития проекта и он будет требовать постоянной переделки, его нельзя будет использовать в другом проекте.

Цитата

Лучше день потерять, потом за 5 минут долететь!

Цитата(Lamer @ 20.2.2005, 13:09)

"Коммонс" - это библиотеки common-net и еще несколько common-что-то, да?

Ага.

Один раз в жизни написать свой connection pool надо.
Таким образом ты сталкиваешься с проблемами, которые возникают
по ходу решения и понимаешь идею.
Легче дальше программировать будет.
Главное - думать в правильном направлении.

Можно, например, так реализовать.
Правда за ошибками снаружи придется следить.

Код

import java.sql.Connection; import java.sql.Statement; import java.sql.DriverManager; import java.sql.SQLException; /** * Название говорит само за себя. */ final class ConnectionPool {    private Connection[] c;//массив подключений    private Statement[] s;//массив утверждений    private boolean[] b;//флаги занятости утверждений    private int size;//размер масиивов    //переменные чтоб в методах не создавать    private int i;//индекс массивов //----Конструктор-------------------------------------------------------    private ConnectionPool(String driver, String url, String user,                           String password, int _size)            throws ClassNotFoundException, SQLException {        size=_size;        c=new Connection[size];        s=new Statement[size];        b=new boolean[size];        Class.forName(driver);        int i;        for(i=0;i<size;i++){            c[i]=DriverManager.getConnection(url,user,password);            s[i]=c[i].createStatement();            b[i]=false;        }    } //----Метод создания объекта--------------------------------------------    final static ConnectionPool getInstance(String driver, String url,                                     String user, String password,                                     int size){        try{            Class.forName(driver);        }catch(ClassNotFoundException e1){            return null;        }        try{            Connection c=DriverManager.getConnection(url,user,password);            Statement s=c.createStatement();            s.close();            c.close();        }catch(SQLException e2){            return null;        }        try{            ConnectionPool cp=new ConnectionPool(driver, url, user,                    password, size);            return cp;        }catch(ClassNotFoundException e1){            return null;        }catch(SQLException e2){            return null;        }    } //----Метод захвата утверждения-----------------------------------------    final synchronized Statement getStatement(){        for(i=0;i<size;i++){            if(!b[i]){                b[i]=true;                return s[i];            }        }        return null;    } //----Метод освобождения утверждения------------------------------------    final synchronized boolean getBack(Statement _s){        for(i=0;i<size;i++){            if(s[i]==_s){                b[i]=false;                return true;            }        }        return false;    } //----Метод для закрытия пула-------------------------------------------    final synchronized boolean close(){        //если ресурс занят - то не заканчиваем работу        for(i=0;i<size;i++){            if(b[i]){                return false;            }        }        boolean error=false;        //закрываем подключения и утверждения        for(i=0;i<size;i++){            try{                s[i].close();            }catch(SQLException e1){                error=true;            }            try{                c[i].close();            }catch(SQLException e2){                error=true;            }        }        return !error;    } }

Извиняюсь. getInstance, естественно, должен быть static

Это сообщение отредактировал(а) Slavca - 23.2.2005, 10:29

Slavca
Большое спасибо за пример, посмотрю на досуге.

у resin-a тоже есть pool, можешь использовать

ZAVS
Спасибо
Мне пока не для реального использования, просто пощупать в свободное время.

Цитата(Slavca @ 21.2.2005, 09:27)

Один раз в жизни написать свой connection pool надо.

Написать надо, а на вот использовать на production не надо. Чтобы написать хороший пул надо очень хорошо разбираться в этом деле. Например в твоем сразу видно критический недостаток - все соеденения открывается сразу и к тому же сразу создается множество statements. Это сразу выделяет кучу ресурсов, которые чаще всего не будут использованны. Если у тебя, к примеру, три Tomcat'a на каждом по три сайта и каждый из них создает пул из 50 коннектов - то у тебя сразу создается 450 подключений, что уже может привести к тому, что все это дело рухнет. Говорят, что даже для того, чтобы поддерживать открытое соеденение MS SQL сервер выделяет около мегабайта памяти. Заодно скажу, что у нас общее количество сайтов работающих с одной и той же БД в три-четыре раза больше как минимум.

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

Поскольку тред достаточно старый (я на Винграде появился спустя два месяца), то на глаза он мне раньше не попадался, а сегодня Lamer George дал на него ссылку в другом топике, ну и вот я значить из интереса зашел и глянул, о чем тут пишут.

Самое главный вывод: ТОВАРИЩИ, НЕ ПОЛЬЗУЙТЕСЬ ПРИМЕРОМ, который дал Slavca. Ни для каких целей: ни для продакшена, ни в качестве отправной точки при разработке собственного пула, ни как образец программного дизайна. Пример - просто из рук вон.

Slavca, не обижайся. Молодец, что проявил инициативу и запостил код. Далее, ты совершенно справедливо говоришь, что "один раз в жизни написать свой connection pool надо". Действительно, надо. Дальше потом жить будет проще. Но надо также, чтобы нашелся человек, который прошелся бы по твоему коду с красным карандашом в руке и указал, чем плоха твоя самодельная реализация.

Так вот, единственно с целью предостеречь возможных последователей от повторения твоих ошибок, беру в руки красный карандаш и начинаю править. Итак:

1. Зачем раздавать статементы вместо соединений???

Любой человек, который сталкивался с мало-мальски слоожными датабазными приложениями, знаком с понятием транзакции. Так вот, транзакция в теминах JDBC имеет область действия в пределах соединения, а не команды SQL! Из статемента, конечно, соединение тоже можно вытащить: statement.getConnection(), но зачем так делать, когда логически гораздо естественнее выдавать его прямо из пула?

Кроме того, не все всегда делается статементом. Иногда полезнее использовать PreparedStatement, а иногда бывает нужен CallableStatement.

2. Привязка к приприеторному API

Если ты в своей программе станешь использовать пул в таком виде, как ты его написал, то в каждом месте кода, где требуется доступ к БД, тебе придется писать примерно такое:

Код

ConnectionPool pool = ConnectionPool.getInstance("connection params..."); Statement stm = pool.getStatement(stm); int n = stm.executeQuery("update some_table set some_field=10 where some_id="25""); stm.close(); // важно! stm.getConnection().close(); pool.getBack(stm);

Если программист, который использует твой пул, забудет последнюю строчку, то рано или поздно массив забъется невозвращенными статементами, и больше никто никаких соединений получить не сможет. Причем это может произойти не только по причине забывчивости, но и в результате небрежного оформления кода доступа к данным, потому что по-грамотному строчка pool.getBack(stm) должна быть заключена в секции finally блока try/catch/finally.

Но это касается датабазного кода вообще, и с этой точки зрения действия connection.close() и pool.getBack() предъявляют одинаковые требования к программистской дисциплине. А вот что действительно плохо, это что если ты на каком-то этапе решишь использовать другую реализацию пула, то тебе придется в куче мест убирать вызов pool.getBack(). Кстати, getBack - неудачное имя (get back - это возвращаться). Лучше было бы putBack или releaseStatement. Но это детали.

Если ты спросишь, есть ли лучшие альтенрнативы, то ответ будет "Есть!". Для того чтобы сделать пул по возможности более прозрачным для программиста, можно, например, написать свою обертку (wrapper) вокруг объекта типа Connection, которая знает. что делать по close():

Код

public class ConnectionWrapper implements Connection {   private ConnectionPool pool;   private Connection con;   public ConnectionWrapper(Connection con, Connection Pool pool)   {     this.pool = pool;     this.con = con;   }   // delegate all methods on the Connection interface   //  to the underlyong Connection object   public Statement createStatement() throws SQLException   {     return con.createStatement();   } // ...and so on   public void close() throws SQLException   {     con.close();     pool.releaseConnection(con);   } }

При таком подходе использование пула не накладывает никаких дополнительных требований на код доступа к данным, то есть можно использовать объекты типа Connection как обычное JDBC соединение.

3. Ранняя инициализация

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

4. Отсутствие цикла ожидания

А теперь - о самом главном недостатке. Как мы видим из кода, если свободных соединений нет, то пул просто и без затей возвращает нам значение null. Вот это зашибись! Нет бы чуток подождать, да попробовать еще разок, а он хоба - и null.

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

В данном случае код мог бы выглядеть примерно так (несущественные детали опускаем):

Код

public synchronized Connection getConnection() throws SQLException {   try   {     while(true)     {       ConnectionWrapper con = getAvailableConnection();       if (con != null)       {         return con;       }       // all connections are busy       if (list.size() < MAX_CONNECTIONS)       {         return createNewConnection();       }       // otherwise wait till one gets available       wait();     }   }   catch (InterruptedException e)   {     // not much else to do here     logger.error(e.getMessage(), e);     throw new RuntimeException("Could not allocate an SQL connection");   } } public synchronized Connection releaseConnection(ConnectionWrapper con) {   con.setAvailable();   notifyAll(); // Это самая важная часть: разблокировать все ждущие треды                //  и позволить им конкурировать за захват objectMonitor'а } private ConnectionWrapper getAvailableConnection() {     Iterator iter = list.iterator();     while (iter.hasNext())     {       ConnectionWrapper con = iter.next();       if (con.isAvailable())       {         con.setBusy();         return con;       }     }     return null; }

Вот так вот примерно. И это только самая минимально необходимая часть функциональности. Я уже не говорию о таких вещах как конфигурация, логирование, мониторинг и разблокирование подвисших соединений, корректная инициализация и закрытие, и т. д., и т. п.

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

И настанет вам нирвана

Ya posmotrel na Proxool, vrode klasnoya shtyka, vse prosto. No kak etim polzovatsya v realnom prilozenii???

Esli y mne nado vupolnit SQL zapros kakoj kod mne nado napisat'????

Sejchas v moej programe odin Connection katoruj sozdaetsya pri starte programu. Potim kogda ya hocy zapystit' Statemement, PreparedStatement ya dostau Connection(y menya on tolko odin), delau
connection.createStatement(....) i poehali.

Chto mne pomenyat???
Mozhet est eshe primeru ili mozhet est svoii primeru??

Spasibo.

Lamer George, если нужно, вот я недавно разбирался с проблемой доступа к пулу: http://forum.vingrad.ru/index.php?showtopi...=0&#entry502629

A chto naschet Apache DBCP? Kto-to polzovalsya???
I she est c3p0.

Цитата(DEMOVERSION @ 18.10.2005, 12:43)

A chto naschet Apache DBCP? Kto-to polzovalsya???

Пользуюсь постоянно. Хорошая штука.

А можно пример?

и если можно пример для простого приложения, а то я только примеры для веб-програм видел.
у меня простое консольное приложение.

спасибо!

Цитата(DEMOVERSION @ 18.10.2005, 15:16)

А можно пример?

У меня он работает через Apache Torque или Hibernate. Соответственно, прямых обращений к dbcp у меня нет.

Вот ссылка на примеры, идущие с dbcp: Тынц

Род Джонсон в своей статье о Spring Framework пишет (см.полный текст)

Цитата

Главная цель Spring – упростить использование J2EE и способствовать хорошему программированию. Spring не рассчитан на повторное изобретение колеса. Поэтому вы не найдете в Spring пакетов для ведения логов, пулов подключений, или координаторов распределенных транзакций. Все это либо можно найти в open source-проектах (например, Commons Logging, который мы вовсю используем для логирования, или Commons DBCP), ...

Как правильно и эффективно использовать DBCP?
Tomcat+Sybase 12.5
Запустил соответствующие примеры к DBCP все работает, а как правильно использовать DBCP в реальных приложениях?
Есть web-проект/который был сделан без фраймворков/, c JSP, сервлетами и Java классами в которую вынесена логика.
Допустим необходимо при вызове JSP страницы выполнять соответствующий запрос к БД
В классе реализуещем логику вставки в таблицу необходимо вызвать метод класса который предоставляет сервисные возможности для работы с DBCP /я так понимаю/, как должен выглядеть этот самый класс, реализующий логику работы с DBCP? Он будет похож на приводимые в примерах (http://svn.apache.org/viewvc/jakarta/commons/proper/dbcp/trunk/doc/) на DBCP классы:

• BasicDataSourceExample.java 
• JOCLPoolingDriverExample.java
• ManualPoolingDataSourceExample.java 
• ManualPoolingDriverExample.java

Кстати, про то что эти примеры разливаются способом установки свойств я понял, а про остальное еще не совсем...
Какой из этих примеров взять за базовый?

В BasicDataSourceExample.java пример того, как работать со стандартным источником данных DBCP, внутри которого и реализован пул соединений. Остальное - примеры использования источников данных DBCP, которые используют свойство драйвера JDBC самостоятельно создавать пул соединений. Обычно используют BasicDataSource, тогда не зависишь от того реализует драйвер свой пул или нет. Но в твоем случае если СУБД точно не поменяется, то фиолетово, все у Sybase реализовано.

Добавлено @ 11:01 
Кстати, в Tomcat есть connection pool, реализованный на DBCP. Почему его не используешь? Тогда тебе все, что нужно будет - это получить DataSource из JNDI.

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

Т.е. у коннектора к нему? У нас используется Sybase 12.5, и коннектор к нему/ весьма не свежий/ как бы мне этот проект достался "по наследству". Старый программист реализовывал свой "самодельный" конекшин пулл к БД, он им был сам не доволен...


Слышал, вот хотел бы уточнить что это, и как его использовать, у нас Томкат (5.5.12)


Т.е. уже используется либы DBCP??? И по идеи их не надо ставить?


Т.е. почти как в примере BasicDataSourceExample.java?




Это сообщение отредактировал(а) VSergeyV - 20.9.2006, 11:22

Ну если совсем несвежий, то наверное лучше подстраховаться и использовать возможности DBCP. 


Вот здесь готовый рецепт, только для MySQL - http://forum.vingrad.ru/index.php?showtopi...st&p=660286.


Нет, не надо, все уже есть.


Пример - по ссылке.