У меня есть много методов в моем классе базы данных, что все они имеют один оператор, когда мне нужно закрыть соединение? В каждом методе или в конце класса базы данных?Сколько раз я должен закрыть соединение в SQL?
Необходимо закрыть соединение, когда вы закончите свою транзакцию. Поскольку мы не знаем содержимого класса или его использования, невозможно определить, когда ваш доступ к соединению начинается или заканчивается.
На самом деле это может быть даже неверно, если соединение предназначено для конкретного использования, а не в пуле. Вы можете оставить его открытым на время вашего заявления.
Как наилучшая практика, вы должны закрыть соединение в логическом месте после того, как все будет сделано - сразу после того, как все действия базы данных для этой задачи будут выполнены.
Как правило, вы должны закрыть соединение в том же методе, который его открывает. Закрытие и открытие соединений не является трудной задачей, поскольку современные серверы БД поддерживают даже закрытые соединения в режиме «горячего резервирования», поэтому их быстро получают через пул соединений. Оставляя их открытыми, хотя ... это может вызвать у вас неприятности и может стать кошмаром для отладки.
Это зависит от того, когда и как неоднократно вы используете эти методы. Если они последовательны, вы должны закрыть соединение только в конце, а не открывать и закрывать часто
Это во многом зависит от того, что делает ваш класс базы данных. Если ваши методы вызываются индивидуально в разное время, тогда методы должны отвечать за открытие и закрытие соединения. Однако, если класс выполняет какую-то большую операцию обработки, которая вызывает много методов, тогда вы можете открыть и закрыть соединение за пределами отдельных методов.
Самое главное, чтобы везде, где вы открываете соединение, вы также закрываете соединение. В противном случае вы начинаете делать предположения о состоянии соединения, которое может вызвать у вас неприятности.
Мы обнаружили, что лучшая политика заключается в том, чтобы получить соединение из пула соединений, выполнить одну транзакцию и сразу же подключить соединение обратно в пул. Таким образом, вы не подключаете соединение для длинных блоков логики, тем самым предотвращая использование других потоков - что является проблемой для масштабируемости.
Закрыть соединение (и заявление и ResultSet!) В же метод блока, как вы приобрели его в finally блоке try блока, где они открыты.
Общий идиома:
public void doSomething() throws SQLException {
Connection connection = null;
try {
connection = database.getConnection();
} finally {
if (connection != null) try { connection.close(); } catch (SQLException logOrIgnore) {}
}
}
Закрытие соединения, заявление и результирующий должно происходить в обратном порядке, как они открыты.
Если ваша проблема связана с производительностью, рассмотрите возможность использования пула соединений для улучшения производительности соединения, например C3P0. Это, кстати, нет изменить общую идиому. Просто продолжайте писать ту же самую идиому, реализация пула соединений будет беспокоить себя дальше под капотами.
Также см. this article для получения дополнительной практики/примеров.
Всегда закрывайте соединение, когда вы завершаете выполнение транзакции.Хорошей практикой является получение и закрытие соединения в том же методе. Если у вас есть отдельные транзакции, которые тесно связаны, вы можете выполнить их с одним и тем же соединением, но для лучших практик я пытаюсь выполнить одну транзакцию для каждого соединения.
Если это вариант, не допускайте явных конфликтов с соединениями. Используйте полномасштабную структуру orm, такую как спящий режим, или используйте что-то значительно более легкое, например, весенние шаблоны jdbc.
использование Ломбок и он будет обрабатывать оба пытаются/улова и conn.Close() для вас
public void doSomething() throws SQLException {
@Cleanup Connection connection = database.getConnection();
}
Это несколько зависит от контекста, приложение работает. Если это веб-приложение вам нужно быть осторожным, чтобы открыть ваше соединение, выполнить любую работу и быстро закрыть соединение. Однако в C/S или пакетной среде может быть лучше получить соединение и удерживать его, если пользователь взаимодействует «часто» (для любого значения «часто» вы выбираете), особенно если у пользователя есть ожидания быстрого времени отклика, и это дорого (с точки зрения времени или ресурсов) для получения соединения с вашим конкретным разнообразием базы данных.
Мне нравится устанавливать таймер каждый раз, когда пользователь имеет приложение, идущее в базу данных. Если/когда таймер истечет, закройте соединение, а затем повторно откройте его в следующий раз, когда он/она захочет снова попасть в базу данных. Время истечения срока действия таймера может составлять от 1 до 20 минут. До тех пор, пока это меньше, чем время «бездействия» базы данных.
Делитесь и наслаждайтесь.