Поскольку тред достаточно старый (я на Винграде появился спустя два месяца), то на глаза он мне раньше не попадался, а сегодня Lamer George дал на него ссылку в http://forum.vingrad.ru/index.php?showtopic=67343, ну и вот я значить из интереса зашел и глянул, о чем тут пишут.
Самое главный вывод: ТОВАРИЩИ, НЕ ПОЛЬЗУЙТЕСЬ ПРИМЕРОМ, который дал 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;
}
|
Вот так вот примерно. И это только самая минимально необходимая часть функциональности. Я уже не говорию о таких вещах как конфигурация, логирование, мониторинг и разблокирование подвисших соединений, корректная инициализация и закрытие, и т. д., и т. п.
Поэтому. После того как вы напишите свою реализацию пула (можно взять за основу мои правки) и убедитесь, что она худо-бедно работает, нужно будет взять и все нафиг грохнуть, а потом пойти и взять нормальный готовый продукт. Например, такой как http://proxool.sourceforge.net/index.html. И увидеть разницу.
И настанет вам нирвана 
|
