You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2012/12/21 12:31:49 UTC
[Bug 54337] New: StatementCache leaks statements/cursors
https://issues.apache.org/bugzilla/show_bug.cgi?id=54337
Bug ID: 54337
Summary: StatementCache leaks statements/cursors
Product: Tomcat Modules
Version: unspecified
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: jdbc-pool
Assignee: dev@tomcat.apache.org
Reporter: patric@rufflar.com
Classification: Unclassified
It seems that the StatementCache has issues in highly multi-threaded situations
where high numbers of PreparedStatements are created.
The application quickly fails with the well-known "Internal Exception:
java.sql.SQLException: ORA-01000: maximum open cursors exceeded"
Without the StatementCache the application just runs fine.
All threads invoke the same SQLs. Of course, each thread uses its own
Connection exclusively.
Two things are conspicuous:
1.
The AtomicInteger field
org.apache.tomcat.jdbc.pool.interceptor.StatementCache.cacheSize
which seems to be not in sync with the real size of the cache Map.
It's too high (higher than 50) and the StatementCache (erroneously) assumes
that the cache capacity is exceeded.
I suggest calling size() on the cache Map instead.
2.
When the capacity seems (or really is) exceeded, statement.close() will not
causing to close the wrapped statement causing the cursor to leak.
The reason can be seen in
org.apache.tomcat.jdbc.pool.interceptor.StatementCache$CachedStatement.closeInvoked()
line: 244-288:
closed = true;
delegate = null;
if (shouldClose) {
super.closeInvoked();
}
The delegate is set to null but only _afterwards_ super.closeInvoked() is
invoked which is unable to close the underlying preparedStatement => the
statement remains unclosed. It should be the other way round.
Best regards,
Patric
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 54337] StatementCache leaks statements/cursors
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54337
Konstantin Kolinko <kn...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
OS| |All
--- Comment #1 from Konstantin Kolinko <kn...@gmail.com> ---
(In reply to comment #0)
> 1.
> The AtomicInteger field
> org.apache.tomcat.jdbc.pool.interceptor.StatementCache.cacheSize
> which seems to be not in sync with the real size of the cache Map.
> (..)
You are wrong:
Map is per-connection. Size is per-pool.
> 2.
> When the capacity seems (or really is) exceeded, statement.close() will not
> causing to close the wrapped statement causing the cursor to leak.
Yes, it is a bug. Duplicate of 54732.
*** This bug has been marked as a duplicate of bug 54732 ***
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org