Stacktrace всегда показывает вам, что текущий поток делал в тот момент. Так что прохождение трассировки стека за строкой - это довольно хорошее исследование для вашей конкретной проблемы.
В вашей трассировке стека есть 5 рабочих строк, чтобы вы могли понять - через которые я пробежусь.
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:329)
Это класс Weblogic Internal, представляющий начало вызова для получения соединения из пула, после чего Weblogic не обнаруживает ни одного доступного из-за утечки
at com.oco.util.BEndOcDBConnectionPool.getConnection(BEndOcDBConnectionPool.java:188)
at com.oco.util.BEndOcDBConnectionPool.getConnection(BEndOcDBConnectionPool.java:144)
at com.oco.util.BEndConnectionManager.getConnection(BEndConnectionManager.java:38)
Это 3 строки из кода вашего приложения, который является ConnectionManager, который выбирает соединение. Я полагаю, что это центральная ответственность за управление всеми соединениями JDBC в вашем приложении - так что именно здесь вы должны посмотреть, что пошло не так.
at com.oco.ejb.confirmation.OrderConfirmationBean.saveConsents(OrderConfirmationBean.java:10213)
Эта конкретная строка no 10213 метода OrderConfirmationBean saveConsents выполняет вызов к BEndConnectionManager - это само по себе может и не быть проблемой, то, что происходит, когда он делает вызов, вызывает проблему.
Итак, подведем итог: начните со строки № 10213 OrderConfirmationBean saveConsents, и вы увидите, что вызов BEndConnectionManager может не закрывать соединения - теперь проверьте ваш код на , чтобы проверить, выполнены ли закрывающиеся соединения или нужно быть сделано в OrderConfirmationBean или самим BEndConnectionManager.
Обновление со ссылкой на BEA-001074
Я сосредоточился больше на трассировке стека, чем на BEA-001074.
Таким образом, BEA-001074 - это сообщение Finalizer , выдаваемое при запуске сборщика мусора (GC). Итак, мое понимание того, что происходит:
Соединение было использовано, но не закрыто в коде, поэтому некоторая ссылка остается в куче JVM сервера Weblogic. Через некоторое время, когда GC запускается, он понимает, что соединение больше не активно, и запускает Finalizer непосредственно перед сборкой мусора. Затем BEA выдает ошибку BEA-001074, чтобы сообщить нам, что потенциальная утечка была устранена путем удаления ссылки и возврата соединения в пул.
Чтобы прояснить ваш вопрос, похоже, что это НЕ во время получения нового соединения, как предполагал мой первоначальный ответ.
Weblogic способен воспроизводить трассировку стека , ссылаясь на точку, в которой соединение (которое должно было быть закрыто) было фактически открыто .
Некоторое чтение на форумах Oracle показывает, что в некоторых версиях 8.1 они не могут воспроизводить трассировку стека, которая показывает Null exception passed - так что в вашем случае это хорошо и работает, что вы можете увидеть фактический стек.