Почему соединения сохраняются, когда я отменяю развертывание веб-приложения с помощью пула соединений Tomcat 7 JDBC?

У меня есть минимальное веб-приложение Spring, развернутое на Tomcat 7.0.22, — оно состоит из пары страниц, контроллера, службы и DAO, у которого есть один метод, выполняющий запрос SELECT.

Веб-приложение настроено на использование нового пула соединений Tomcat JDBC. вот конфигурация ресурса в context.xml веб-приложения:

<Resource name="jdbc/myDB"
          auth="Container"
          type="javax.sql.DataSource"
          driverClassName="oracle.jdbc.OracleDriver"
          url="jdbc:oracle:thin:@blah blah"
          factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
          maxActive="15"
          initialSize="5"
          maxWait="40000"
          validationQuery="select 1 from dual"
          removeAbandoned="true"
          removeAbandonedTimeout="300"
          logAbandoned="false"
          username="user"
          password="pass"
          testOnBorrow="true"
          validationInterval="30000"
          timeBetweenEvictionRunsMillis="60000"
          minEvictableIdleTimeMillis="60000" />

Когда я развертываю веб-приложение, я вижу 5 подключений (запрос v$session от SQL Developer). Когда я отключаю веб-приложение, соединения сохраняются (в состоянии ОЖИДАНИЕ). Каждый раз, когда я повторно развертываю свое веб-приложение, появляются 5 новых подключений.

Похоже, что пул все еще висит вокруг, и кнопка «Найти утечки» в приложении менеджера Tomcat сообщает мне, что в приложении происходит утечка памяти.

Как избавиться от пула, если веб-приложение не развернуто?


jdbc connection-pooling tomcat tomcat7
person Paul    schedule 08.12.2011    source источник

Ответы (3)


arrow_upward
5
arrow_downward

Проблема была вызвана самим собой (как и большинство). Мой источник данных был настроен в файле web.xml моего веб-приложения, и я ссылался на него через JNDI. Теперь я создаю свой источник данных, как показано в справочном документе Spring (раздел 13.3.1), а метод destroy позаботится о закрытии источника данных и пула.

Если бы мне пришлось придерживаться источника данных JNDI, мне пришлось бы закрыть источник данных в классе, реализующем ServletContextListener, в методе contextDestroyed.

person Paul    schedule 23.12.2011

arrow_upward
2
arrow_downward

Об этом сообщается в багзилле Apache Tomcat, ссылка:

https://issues.apache.org/bugzilla/show_bug.cgi?id=25060

Это было исправлено с Tomcat 7.0.11. Какую версию Tomcat вы использовали?

Если вы используете создание источника данных, как описано в справочнике Spring на «уровне приложения», у вас будут небольшие накладные расходы, когда дело доходит до задач администрирования, если у вас много приложений и много серверов.

person Brian    schedule 04.09.2012

arrow_upward
2
arrow_downward

У меня была та же проблема, и я не мог использовать Spring, поэтому я использовал org.apache.tomcat.jdbc.pool.DataSourceProxy, чтобы закрыть источник данных Tomcat. Этот API предоставляет вам функциональные возможности, еще не реализованные в интерфейсе JDK DataSource.

DataSourceProxy myDataSource = (DataSourceProxy) myDataSource;
myDataSource.close();
  • Также используется factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" и метод contextDestroyed ServletListener.
person PbxMan    schedule 21.08.2014
comment
Спасибо, я не знал об этом классе ... очень полезно! - person Paul; 21.08.2014