akril 9 авг 2010 в 20:29

Database Connection Pool

3 мин

160K

Java*

+19

Комментарии 38

adontz 9 авг 2010 в 20:51

Понятно что решение обобщённое и подходит для любых ресурсов, а не только соединений с БД, но неужели нельзя в строке подключения указать что-то вроде «Pooling=yes»?

norguhtar 10 авг 2010 в 01:17

У драйвера нельзя, он низкоуровневый и с такими категориями не работает.

adontz 10 авг 2010 в 09:23

Печально как-то у вас это…

norguhtar 10 авг 2010 в 10:23

У нас все хорошо :]

Kodeks 10 авг 2010 в 02:54

Обожаю статьи типа «Две недели назад я начал заниматься… и вот я решил написать статью...»

Insar 10 авг 2010 в 03:53

Мне тоже понравились «письменные мысли путем написания...». :-)

akril 10 авг 2010 в 04:35

Спасибо, поправил :)

mgyk 10 авг 2010 в 03:32

Мне всегда нравилась JAVA. Пачка фаилов, для того чтобы только подключится к БД

Gregy 10 авг 2010 в 04:10

Наверное правильнее сказать что всего 2 файла и получаем пул соединений. :)

akril 10 авг 2010 в 04:37

Вы не правы. Захардкодить подключение можно одной строчкой, а пачкой файлов можно добиться гибкости.

licvidator 10 авг 2010 в 08:43

Connection conn = DriverManager.getConnection(«jdbc:oracle:thin:127.0.0.1:1521», «system», «sys»);

Реквестирую пачку файлов. Кроме JDBC-драйвера естественно.

akril 10 авг 2010 в 08:51

ну, вообще-то именно это и называется «захардкодить одной строчкой» :)

Shaytank 10 авг 2010 в 04:45

Замечу, что у вас возникнет проблема, если maxWait будет больше чем connection_timeout базы данных. Лучше посмотреть эту ссылку commons.apache.org/dbcp/configuration.html и дописать конфиг

Shaytank 10 авг 2010 в 04:47

Хотя нет, не так. Не от maxWait это зависит. У нас была проблема с тем, что соединения отвалившиеся по таймауту оставались в пуле

Psych0 10 авг 2010 в 21:59

У нас на проекте тоже были проблемы… Мы их «решали» давольно легким способом — перед выполнением запроса делали фейковый запрос к БД. Если он срабатывал, то все хорошо, иначе пересоздавали, хотя система считала, что все нормально… ведь у нее же было открытое потключение :)

Shaytank 11 авг 2010 в 04:34

Настройка validationQuery почти этим и занимается. Думаю удобней один раз в конфиге прописать и забыть о проблеме вобще)

Butylski 10 авг 2010 в 05:05

Две недели назад я начал писать на Java и теперь, дорогие хабралюди, я расскажу вам о чудном способе вывода «Hello, world»… [*сарказм*]

pokryshkin 10 авг 2010 в 05:23

Так это про кого.

НЛО прилетело и опубликовало эту надпись здесь

konsoletyper 10 авг 2010 в 05:28

Сдаётся мне, что главная причина, по которой используется пул соединений — это возможность одновременной работы нескольких потоков (threads) приложения. В противном случае потоку, который открывает транзакцию, пришлось бы ещё и тормозить остальные потоки. Кстати, странно, что используется работа с БД напрямую. Есть же JPA, есть же Hibernate. Насколько я знаю, для них пул можно настроить специфическим механизмом.

pokryshkin 10 авг 2010 в 05:35

В посте правильно написано, главная причина — исключить затраты на открытие/закрытие соединения.

konsoletyper 10 авг 2010 в 08:36

Ну не совсем правильно выразился. В посте написано, что можно было бы использовать singleton, но лучше его не использовать, т.к. это пагубно скажется на производительности. А как раз поднимать только одно соединение на всё приложение чревато не столько снижением производительности, сколько невозможности одновременной обработки нескольких запросов.

Timmmm 10 авг 2010 в 07:44

Не поверите, «для них пул можно настроить специфическим механизмом» внутри hibernate пула лежит примерный такой же механизм описанный автором.

konsoletyper 10 авг 2010 в 08:38

Да, работают они все так же. Но внутри Hibernate использует пул по умолчанию. Кроме того, можно (и нужно в продуктиве) настраивать пул специально для Hibernate. В этом случае настройка пула выглядит несколько иначе, чем описано в статье.

Colwin 10 авг 2010 в 05:38

Я бы добавил к статье следующее замечание.
Перед возвратом соединения в пул все Statement'ы и ResultSet'ы, полученные с помощью этого соединения, автоматически закрываются в соответствии с API.

romychs 10 авг 2010 в 06:23

Ну да, так оно и есть. Главное не забывать, что соединение необходимо вовремя закрывать, иначе можем запросто переполнить пул соединений и очередь. Statement и ResultSet тоже лучше закрывать, если они больше не нужны. У меня эта привычка осталась с «древних» времен Turbo C/Pascal когда самому приходилось следить за ресурсами. С моей точки зрения привычка «убирать за собой» при работе приложения на сервере приложений, это хорошая привычка. Каждый объект, будь то EJB, Servlet и пр. имеет свой жизненный цикл и тут уже нельзя полагаться на то, что конкретный экземпляр умрет сразу после обращения и GC унесет весь мусор связанный с ним.

НЛО прилетело и опубликовало эту надпись здесь

javax 10 авг 2010 в 06:03

А еще удобнее этим через Spring пользоваться — он сам «вставит» Connection Pool в ваши классы

neoroma 10 авг 2010 в 06:14

Похоже вся соль этой статьи выплывает в комментариях)

НЛО прилетело и опубликовало эту надпись здесь

thevery 10 авг 2010 в 10:34

это, собственно, одна из главных опций, а автор про неё почему-то и не упомянул…

andreycha 10 авг 2010 в 07:38

В конце, как обычно, следует закрыть соединение (conn.close()), однако в отличии от обычного соединения через драйвер JDBC, это соединение на самом деле не закроется: оно будет помечено в пуле как свободное, и его можно будет переиспользовать позже.

Каким образом об этом узнает пул? Как осуществляется обратная связь?

andreycha 10 авг 2010 в 07:42

По ссылке на мануал написано, что идет не закрытие соединения, а его возврат в пул:

pool.returnConnection(this);

Jedi_Knight 10 авг 2010 в 14:54

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

Jedi_Knight 10 авг 2010 в 14:54

В таком случае Resource записывается в контекст приложения

synck 10 авг 2010 в 19:35

Основываясь на практическом опыте, могу сказать, что стоит весьма трепетно отнестись к производительности самого пула.

dbcp отличается низкой производительностью. В случае большого количества параллельных обращений к пулу он становится существенным затыком во всей системе. Проблема заключается в неэффективной реализации контейнера объектов (собственно говоря commons-pool), которая использует java synchronized.

Есть несколько альтернатив dbcp: c3p0, proxol, nanopool, miniconanectionpool, Oracle jdbc connection pool и др. После сравнительных тестов производительности мы выбрали Tomcat JDBC Connection Pool. Он использует java concurrent collections, прост в использовании и расширении, а конфигурация совместима c dbcp. Пропускная способность нашего приложения после этой замены варосла приблизительно на 30%.

Throwable 11 авг 2010 в 07:50

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

Kotovoin 17 мая 2015 в 14:39

Поправил ошибки.

<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/appname</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>

InitialContext initContext= new InitialContext();
DataSource ds = (DataSource) initContext.lookup("java:comp/env/jdbc/appname");
Connection conn = ds.getConnection();

У меня была ошибка: сannot create JDBC driver of class '' for connect URL 'null'
Исправил context.xml так:

<?xml version="1.0" encoding="UTF-8"?>
<Context>   
   <Resource name="jdbc/appname" auth="Container"
				type="javax.sql.DataSource" maxActive="100" 
				maxIdle="30" maxWait="10000"
				username="username" 
				password="password"
				driverClassName="jdbc.driver.name"
				url="jdbc:protocol://hostname:port/dbname"/>
</Context>

Зарегистрируйтесь на Хабре, чтобы оставить комментарий