Закрытие соединений JDBC в пуле

Наш стандартный раздел кода для использования JDBC...

Connection conn = getConnection(...);
Statement  stmt = conn.conn.createStatement (ResultSet.TYPE_SCROLL_INSENSITIVE,
                                                ResultSet.CONCUR_READ_ONLY);
ResultSet  rset = stmt.executeQuery (sqlQuery);

// do stuff with rset

rset.close(); stmt.close(); conn.close();

Вопрос 1: При использовании пула соединений следует закрыть соединение в конце? Если да, то не цель объединения потерянных? А если нет, то как DataSource знает, когда конкретный экземпляр Connection освобождается и может быть повторно использован? Я немного смущен этим, любые указатели оценили.

Вопрос 2: Является ли следующий метод чем-то близким к стандарту? Попытка получить соединение из пула, и если DataSource не может быть установлен, используйте старомодный DriverManager. Мы даже не уверены, какая часть будет выполняться во время выполнения. Повторяя вопрос выше, следует ли закрыть соединение, исходящее из такого метода?

Спасибо, - MS.

synchronized public Connection getConnection (boolean pooledConnection)
                                                        throws SQLException {
        if (pooledConnection) {
                if (ds == null) {
                        try {
                                Context envCtx = (Context)
                                        new InitialContext().lookup("java:comp/env");
                                ds = (DataSource) envCtx.lookup("jdbc/NamedInTomcat");
                                return ds.getConnection();
                        } catch (NamingException e) {
                                e.printStackTrace();
                }}
                return (ds == null) ? getConnection (false) : ds.getConnection();
        }
        return DriverManager.getConnection(
                "jdbc:mysql://"+ipaddy+":"+dbPort +"/" + dbName, uName, pWord);
}

Изменить: Я думаю, что мы получаем объединенное соединение, так как мы не видим трассировку стека.

Ответ 1

При использовании пула соединений следует закрыть соединение в конце? Если да, то не цель объединения потерянных? А если нет, то как DataSource знает, когда конкретный экземпляр Connection освобождается и может быть повторно использован? Я немного смущен этим, любые указатели оценили.

Да, конечно, вам нужно также закрыть объединенное соединение. Это фактически обертка вокруг фактического соединения. Он под крышкой отпускает фактическое соединение обратно в бассейн. Далее в пул можно решить, действительно ли фактическое соединение будет закрыто или повторно использовано для нового вызова getConnection(). Таким образом, независимо от того, используете ли вы пул соединений или нет, вы должны всегда закрывать все ресурсы JDBC в обратном порядке в блоке finally блока try, где вы приобрели их. В Java 7 это можно упростить, используя try-with-resources.

Является ли следующий метод чем-то близким к стандарту? Попытка получить соединение из пула, и если DataSource не может быть установлен, используйте старомодный DriverManager. Мы даже не уверены, какая часть будет выполняться во время выполнения. Повторяя вопрос выше, следует ли закрыть соединение, исходящее из такого метода?

Пример довольно пугающий. Вам просто нужно искать/инициализировать DataSource только один раз во время запуска приложения в некотором конструкторе/инициализации базового конфигурационного класса DB. Затем просто вызовите getConnection() на один и тот же источник данных на протяжении всего срока службы приложения. Нет необходимости в синхронизации и nullchecks.

См. также:

Ответ 2

Пулы обычно возвращают вам завернутый объект Connection, где метод close() переопределяется, как правило, возвращает соединение с пулом. Вызов close() в порядке и, возможно, все еще требуется.

Метод close(), вероятно, будет выглядеть следующим образом:

public void close() throws SQLException {
  pool.returnConnection(this);
}

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