Проблема с не заключительное соединение дб при отладке?
У меня есть приложение Java, которое открывает соединение с базой данных вначале и закрывает его в конце. Однако программа не всегда заканчивается, потому что исключение выдается, или я отлаживаю его и останавливаю его на полпути через.
Это заставит открытые соединения накапливаться и замедлять базу данных, или она будет очищена автоматически?
4 ответа
Соединение базы данных принадлежит и управляется базой данных, класс просто дает вам доступ к этому ресурсу базы данных. Если вы не закроете соединение, то класс Java может быть собранным мусором, но база данных может не сказать, что соединение больше не используется, что может привести к потрачению ресурсов баз данных (до учета тайм-аута на стороне базы данных ) или даже утечка.
Итак, когда вы закончите с использованием вашего соединения , вы должны быть уверены , чтобы явно закрыть его, вызывая его , близко () . Это позволит сборщику мусора вспомнить память как можно раньше, а более важно , оно освобождает любые другие ресурсы базы данных (курсоры, ручки и т. Д.). Соединение может удерживать.
Традиционный способ сделать это в Java, заключается в том, чтобы закрыть ваш результаты , , , и соединение (в этом порядке) в , наконец, Блок, когда вы закончите с ними, и безопасный шаблон выглядит так:
Connection conn = null;
PreparedStatement ps = null;
ResultSet rs = null;
try {
// Do stuff
...
} catch (SQLException ex) {
// Exception handling stuff
...
} finally {
if (rs != null) {
try {
rs.close();
} catch (SQLException e) { /* ignored */}
}
if (ps != null) {
try {
ps.close();
} catch (SQLException e) { /* ignored */}
}
if (conn != null) {
try {
conn.close();
} catch (SQLException e) { /* ignored */}
}
}
Наконец , наконец, блок может быть немного улучшенным в (чтобы избежать нулевой проверки):
} finally {
try { rs.close(); } catch (Exception e) { /* ignored */ }
try { ps.close(); } catch (Exception e) { /* ignored */ }
try { conn.close(); } catch (Exception e) { /* ignored */ }
}
, но все же, Это очень многословный, поэтому вы, как правило, в конечном итоге используете класс помощника, чтобы закрыть объекты в нуле-безопасных помощниках помощника и , наконец, , наконец, блок становится что-то в этом роде:
} finally {
DbUtil.closeQuietly(rs);
DbUtil.closeQuietly(ps);
DbUtil.closeQuietly(conn);
}
и, на самом деле, Apache Commons dbutils имеет класс DBUTILS , который точно делает это, так что нет необходимости писать свои собственные.
В вашем случае это решит проблему исключения, но не отладка одного (и вы будете тратить ресурсы базы данных до тех пор, пока на стороне тайм-аута не произойдет на стороне базы данных). Итак, 1. Не отлажите свой код с помощью производственной базы данных 2. Попробуйте выполнить сеанс отладки до конца.
Ваш сервер DB будет иметь настройку времени ожидания. Он закроет соединение и откатывает любые незарегистрированные транзакции. Это происходит на протяжении десятилетий на любом продукте DB производства.
Если вы хотите сделать это правильно использовать попытку {..your Code ..} Наконец {..Close Connections ..}
Нет.
Если ваша программа продолжается, а ваши соединения живы, то Bd просто отклонил ваше предложение.
Если что-то случилось с вашим подключением (на примере, тайм-аут), то BD был закрыт это соединение, и он не употребляет ресурсы.
Если вы выпустили ваше соединение, и сборщик мусора был вызван (его может быть некоторое время). Соединение закроется сама до освобождения.
Если ваша программа заканчивается без закрытия вашего соединения, то все (операционную систему) процесс выпустит свои собственные ресурсы и между ними, нативным ресурсом, который подключен к BD (вероятным сетевым сокетом). BD затем получит соединение прерванию / закрытому и отпустите ваше соединение.
Единственное, что может произойти, так это то, что одно единственное исполнение будет подключаться к BD много раз и очень плохо держать их открытыми, ocuppying все доступные соединения. Но это не твой случай, я думаю.
Редактировать : В целом BD сделаны плохое клиентское поведение - понятный
Вот что говорит Sun (err...Oracle?) :
Программистам рекомендуется явно закрывать созданные ими соединения и утверждения, когда они больше не нужны.
Программисту, пишущему код на языке программирования Java и не использующему внешние ресурсы, не нужно беспокоиться об управлении памятью. Сборщик мусора автоматически удаляет объекты, когда они больше не используются, и освобождает используемую память. Когда память иссякает, он перерабатывает выброшенные объекты, делая память, которую они занимают в настоящее время, доступной для быстрого повторного использования.
Однако, если приложение использует внешние ресурсы, как это происходит при обращении к СУБД с помощью JDBC API, сборщик мусора не имеет возможности узнать состояние этих ресурсов. Он все равно будет перерабатывать выброшенные объекты, но если в Java куче много свободной памяти, то сборщик мусора может собирать мусор нечасто, даже несмотря на то, что (небольшое) количество Java-мусора вмещает в себя открытые большие объемы дорогих ресурсов СУБД. Поэтому программистам рекомендуется явно закрывать все связи (методом Connection.close) и операторы (методом Statement.close), как только в них отпадет необходимость, тем самым освобождая ресурсы СУБД как можно раньше. Особенно это касается приложений, предназначенных для работы с разными СУБД из-за различий между СУБД и СУБД.
Я поставлю доступ к БД в пробный блок и постараюсь закрыть все утверждения и соединения в конечном блоке.