I just reproduced the memory leak in a plain Tomcat 7.0.34,
using only JDBC and a Mysql datasource:
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("java:/comp/env/jdbc/test");
Connection conn = ds.getConnection();
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM MYTABLE");
ResultSet rs = stmt.executeQuery();
conn.close();
I put the above code in a JSP file, then after each request I
did "jmap -histo:live 4711 | grep com.mysql.jdbc.JDBC4".
The numbers increment steadily.
Adding stmt.close() before conn.close() makes the leak go away.
Using jdbcInterceptors="StatementFinalizer" in the pool helps.
This seems to be the documented way to deal with this. However
when I tried "StatementFinalizer" in TomEE it had no effect.
The attribute was recognized, because if I misspelled the value
I got an error message in TomEE's catalina.out.
With Tomcat and commons-dbcp (the default) it was impossible
to reproduce the memory leak even when I neglected to close
the Connection proxy.
I can provide an isolated TomEE example that reproduces the
problem, but I need to disentangle it from my main project
code first.
--
Bjorn Danielsson
Cuspy Code AB
Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> Hi,
>
> did you try to reproduce it with tomcat-jdbc (in a simple test without
> tomee or any other framework)?
>
> i wonder if it is linked to tomee or tomcat-jdbc directly (or mysql
> since derby seems fine)
>
> any more info or even a test reproducing the issue (in a reasonnable
> time) would be great.
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/1/3 Howard W. Smith, Jr. <smithh032...@gmail.com>:
>> Very interesting info here, thanks for sharing.
>>
>> I have been using TomEE since 1.5.1-SNAPSHOT and now 1.5.2-SNAPSHOT. Also,
>> I'm using Apache Derby 10.9.1.0 and Eclipse 2.3.2, and JDBC configured in
>> tomee.xml.
>>
>> Can you share your JDBC config from your tomee.xml and/or context.xml?
>>
>> Apache Derby is working fine for me, but I think I'm experiencing memory
>> leaks that are possibly caused by Google Calendar API's use of
>> threadlocal/etc... No need to discuss that here in this thread.
>>
>>
>> On Thu, Jan 3, 2013 at 1:54 PM, Bjorn Danielsson <
>> bjorn-apa...@lists.cuspycode.com> wrote:
>>
>>> It doesn't matter if I use Eclipselink instead of OpenJPA.
>>>
>>> But the memory leak goes away if I change the database from Mysql
>>> to embedded Derby, so I assume there is some quirkiness in the
>>> Mysql driver that is involved.
>>>
