Блог

В документации Java по интерфейсу java.sql.Connection говорится следующее о методе close (): «Настоятельно рекомендуется, чтобы приложение явно фиксировало или откатывало активную транзакцию перед вызовом метода close. Если вызывается метод закрытия и имеется активная транзакция, результаты определяются реализацией.»

Это создает тонкую, но серьезную проблему: если я вызываю метод отката() Соединения, но этот метод завершается неудачно (например, происходит тайм-аут), то могу ли я вызвать метод close() этого соединения? Возможно ли, что при вызове метода close() все еще существует активная транзакция, и поэтому результаты определяются реализацией, и поэтому транзакция может быть зафиксирована?

Я могу отказаться от вызова метода close() в случае сбоя функции rollback (), но это может привести к тому, что ресурсы JDBC не будут освобождены. Кроме того, возможно, в конечном итоге будет вызван метод close () (возможно, когда объект подключения будет собран как мусор). Если это так, то такой подход не поможет.

Итак, что я должен делать, когда метод rollback() для соединения завершается сбоем? Если метод rollback() завершится неудачно, могу ли я по-прежнему вызывать метод close() этого соединения?

Если я вызываю rollback() метод a Connection , но этот метод завершается неудачно (например, происходит тайм-аут), то могу ли я вызвать close() метод this Connection ?

Согласно спецификации JDBC, SQLTransactionRollbackException является переходным SQLException .

Переходный SQLException процесс будет возникать в ситуациях, когда ранее неудачная операция может завершиться успешно, когда операция повторяется без какого-либо вмешательства функций уровня приложения. После SQLException того, как SQLTransientConnectionException произойдет переходный процесс, отличный от этого, приложение может предположить, что соединение все еще действует.

Таким образом, если rollback() сбой произошел с an SQLTransactionRollbackException , вы должны иметь возможность close() подключиться или повторить rollback() попытку . (Если бы вы позвонили close() , то после звонка rollback() водителю было бы неправильно совершать транзакцию.)

Однако в случае rollback() сбоя с a SQLTransientConnectionException соединение будет недействительным. Звонок close() может не сработать … или он может зафиксировать транзакцию ¹. Осторожный подход состоит в том , чтобы просто отказаться от Connection и верить, что база данных автоматически откатит транзакцию. В качестве альтернативы, если вы можете выяснить (из документации вашего водителя и т. Д.), Что a close() не будет совершать транзакцию, Затем позвоните close() .

В последнем случае, я думаю, мы должны предположить, что, когда драйвер JDBC обнаружит, что соединение было потеряно, он освободит Socket и другие ресурсы, насколько это возможно. Пользователь Socket , чье сетевое соединение было разорвано, не может быть «повторно открыт», поэтому нет смысла цепляться за него.

Если мы не позвонили close() и просто забыли об Connection этом (после сбоя отката), утечка ресурсов, вероятно, не имеет значения, так как:

• сбои подключения к базе данных должны быть редким явлением,
• GC Java должен в конечном итоге завершить Connection и выпустить соответствующие Socket и т. Д.

^{1 — В теории. В JDBC Javadoc говорится, что не указано, что произойдет, если вы close() подключитесь к активной транзакции. Но было бы полезно проверить документацию для конкретных драйверов, которые вы используете.}