Bug reported at https://issues.apache.org/bugzilla/show_bug.cgi?id=54732
Due to another bug in TomEE, StatementCache is always enabled. That bug
is reported here: https://issues.apache.org/jira/browse/TOMEE-837
Thanks for your help
On 20/03/2013 7:28 AM, Felix Schumacher wrote:
Am 19.03.2013 22:20, schrieb Bertrand Guay-Paquet:
On 19/03/2013 5:05 PM, Felix Schumacher wrote:
Have you looked at
http://grokbase.com/t/openejb/users/13135d2a0v/jdbc-connection-pool-memory-leak
? It seems like your problem. Regards Felix
Indeed, this is extremely similar to my issue. Thanks for sharing this.
It does seem however like the StatementFinalizer Tomcat interceptor
should not be necessary if an application closes its connections,
statements and result sets properly. From what I could see by stepping
in the code, this is the case with MyBatis. The actual source of the
problem really seems to be that Tomcat's jdbc pool swallows calls to
Statement.close() like I showed in my original message.
Now that I had time to look more closely, I believe you are right and
the assignment of 'closed' and 'delegate' before (or even after) the
call to super.closeInvoked() looks like a bug, too.
So I think you should go ahead and file one in bugzilla. You should
keep in mind, that afaik the StatementCache is not enabled by default
in tomcat.
Regards
Felix
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
