Bertrand Guay-Paquet <ber...@step.polymtl.ca> schrieb:
>Hello, > >I'm using Tomcat 7.0.34 via TomEE 1.5.1 with MySQL. I noticed a memory >leak in my web application which uses jdbc connection pooling with >Tomcat's jdbc-pool. > >The com.mysql.jdbc.JDBC4Connection class has a field named >"openStatements" which holds, as you can imagine, open sql statements. >This structure grows continuously over time and no statements are ever >released. I stepped into my code to verify that I closed opened >statements and it is the case. > Have you looked at http://grokbase.com/t/openejb/users/13135d2a0v/jdbc-connection-pool-memory-leak ? It seems like your problem. Regards Felix >Digging some more, I downloaded Tomcat's source and it seems that >jdbc-pool discards all calls to java.sql.Statement.close() in >StatementDecoratorInterceptor#invoke(Object proxy, Method method, >Object[] args) > >I see what could be a bug in StatementCache#closeInvoked() which is >called by the above method. Here is the code with my own comments >added: >@Override >public void closeInvoked() { > boolean shouldClose = true; > if (cacheSize.get() < maxCacheSize) { > // omitted for brievety > } > closed = true; > // [1] I think "delegate = null" is done too soon > delegate = null; > if (shouldClose) { > // check its body below > super.closeInvoked(); > } >} > >// This is super.closeInvoked() >public void closeInvoked() { > if (getDelegate()!=null) { > // never true when coming from > // StatementCache#closeInvoked() > // because of [1] > try { > getDelegate().close(); > }catch (SQLException ignore) { > } > } > closed = true; > delegate = null; >} > >Regards, >Bertrand > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
