Соединение Oracle не закрывается в приложении Java

Важной частью закрытия является то, что происходит на стороне базы данных. Это РСУБД должна закрыть это соединение. Вызов метода close() — это то, что передает сообщение в базу данных, чтобы закрыть соединение.

Установка для соединения значения null не указывает РСУБД что-либо делать.

Та же логика применима к ResultSet, который является курсором на стороне базы данных, и к оператору. Вам нужно закрыть их в отдельных блоках try/catch в блоке finally метода, создавшего их, в порядке, обратном созданию. В противном случае вы увидите ошибки «Превышено максимальное количество курсоров».

Установка для conn значения null только разрывает ссылку на объект соединения и не влияет на то, открыто соединение или нет. Если соединение все еще открыто, то на него все равно будет ссылаться драйвер JDBC/пул соединений и т.д.

Установка переменной в null больше говорит сборщику мусора, что можно очистить исходный объект, когда он этого хочет, чем что-либо еще.

Как говорят другие, здесь у вас есть две разные концепции: закрытие соединения и отслеживание соединения в переменной.

Чтобы закрыть соединение, позвоните по номеру conn.close(). Это не установит для переменной conn значение null. Вы можете проверить, открыто ли соединение с помощью conn.isClosed().

Если вам больше не нужно отслеживать соединение в коде, вы можете conn = null. Это не немедленно закрывает соединение. Я считаю, что соединение будет автоматически закрыто на основе JDBC документация :

Releases this Connection object's database and JDBC resources immediately instead of waiting for them to be automatically released.

Если вы решите пойти по этому пути, имейте в виду, что сборщик мусора может закрыть ваше соединение не так быстро, как вам хотелось бы, и у вас может возникнуть то, что выглядит как утечка ресурсов; зарезервированные блокировки базы данных не будут сняты до тех пор, пока соединение не будет удалено сборщиком мусора. Некоторые драйверы (я не знаю, является ли оракул одним из них) налагают максимальное ограничение на количество подключений, которые могут существовать одновременно, поэтому оставление открытых подключений также может привести к сбоям подключения позже в программе.

Утечки соединения лучше всего. Я думаю, что хорошая стратегия состоит в том, чтобы обернуть получение и освобождение соединений в пару функций, а затем всегда получать и освобождать ваши соединения через эти функции. Затем вы можете заставить эти функции поддерживать список всех открытых соединений и выполнять трассировку стека для вызывающей стороны функции выделения. Затем появится экран со списком всех открытых подключений и их происхождением. Запустите это в тестовой среде, побегайте, используя кучу экранов, затем закройте их все, чтобы все соединения ДОЛЖНЫ были закрыться, затем откройте экран, показывающий открытые соединения, и злодей должен быть раскрыт.

Мое объяснение здесь является обоснованным предположением.

На практике я всегда устанавливал conn=null после закрытия. Я считаю, что когда вы выполняете conn.close(), вы сообщаете сборщику мусора, что он готов к сборке мусора. Однако процесс сборки мусора должен определить, когда это делать.

Также вы можете изменить свой

если (соединение! = ноль)

to

если (conn.isClosed())

..

Есть ли фрагмент кода Java, который может дать мне мои открытые соединения?

Statement smt = null;
    ResultSet rs = null;
    try { 
        // Create Statement from connection
        smt = conn.createStatement();
        // Execute Query in statement 
        rs = stmt.executeQuery("SELECT 1 FROM Dual");

        if (rs.next()) {
            return true; // connection is valid
        }
        catch (SQLException e) {
            // Some sort of logging
            return false;
        }
        finally {
            if (smt != null) smt.close();
            if (rs != null) rs.close();
        }

Просто быстрое предположение, если вы используете Oracle. Предложение: почему бы вам не установить jboss и не настроить там пул соединений?