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 2017/04/21 13:13:41 UTC
[Bug 61022] New: Returning Closed Connections to the Pool
https://bz.apache.org/bugzilla/show_bug.cgi?id=61022
Bug ID: 61022
Summary: Returning Closed Connections to the Pool
Product: Tomcat Modules
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: jdbc-pool
Assignee: dev@tomcat.apache.org
Reporter: glm@hilbertinc.com
Target Milestone: ---
The connection pool was returning a closed connection to the pool. The root
cause of this was that my code was accessing the underlying ("real") connection
and closing it. My code snipped follows:
private void onResultSetExhausted() throws SQLException {
if (!getResultSet().isClosed()) {
Statement statement = getResultSet().getStatement();
if (!statement.isClosed()) {
Connection connection = statement.getConnection();
getResultSet().getStatement().close();
if (!connection.isClosed()) {
connection.close();
}
}
getResultSet().close();
}
}
This implies that the problem may be a regression of the problem described in
48392. My proposed solution is to check the real connection state in the
ProxyConnection::invoke method. A snippet of that code is:
if (compare(CLOSE_VAL,method)) {
if (connection==null) return null; //noop for already closed.
PooledConnection poolc = this.connection;
this.connection = null;
if (!poolc.getConnection().isClosed()) { // <-- Added this
pool.returnConnection(poolc);
}
return null;
} else if (compare(TOSTRING_VAL,method)) {
--
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 61022] Returning Closed Connections to the Pool
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61022
--- Comment #3 from Christopher Schultz <ch...@christopherschultz.net> ---
Are you saying that bug #48392 is actually not completely fixed? 48392 was
reported for getResultSet().getConnection(), but the comments indicate that
also getResultSet().getStatement().getConnection() was fixed as well.
So, are you reporting a regression/incomplete fix for 48392 or am I missing
something else?
--
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 61022] Returning Closed Connections to the Pool
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61022
--- Comment #6 from Gary Murphy <gl...@hilbertinc.com> ---
Thank you. That resolved the issue. Is there documentation for this and other
available interceptors?
--
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 61022] Returning Closed Connections to the Pool
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61022
--- Comment #7 from Christopher Schultz <ch...@christopherschultz.net> ---
You mean like this?
http://tomcat.apache.org/tomcat-8.0-doc/jdbc-pool.html
--
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 61022] Returning Closed Connections to the Pool
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61022
--- Comment #4 from Gary Murphy <gl...@hilbertinc.com> ---
I didn't go back through the source code history, since 48392 was fixed in
2011. I suspect it was fixed properly and regressed at some subsequent
refactor.
I think the proper fix would be the one discussed there - meaning that the
connection should provide a proxy for the statement and the statement should
provide a proxy for the result set. That will keep the semantics of the
Connection class consistent.
However, the fix I made to ConnectionPool to simply check for a closed
connection would be simpler and would resolve my issue. I would be glad to
send that to you for your review if you would like.
--
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 61022] Returning Closed Connections to the Pool
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61022
Christopher Schultz <ch...@christopherschultz.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #1 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to Gary Murphy from comment #0)
> my code was accessing the underlying ("real")
> connection and closing it.
Umm... don't do that / NOTABUG?
--
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 61022] Returning Closed Connections to the Pool
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61022
Keiichi Fujino <kf...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEEDINFO |RESOLVED
--- Comment #5 from Keiichi Fujino <kf...@apache.org> ---
The org.apache.tomcat.jdbc.pool.interceptor.StatementDecoratorInterceptor was
introduced in the fix for 48392.
However, The StatementDecoratorInterceptor is not enabled by default.
You should set StatementDecoratorInterceptor to jdbcInterceptors.
--
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 61022] Returning Closed Connections to the Pool
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61022
--- Comment #2 from Gary Murphy <gl...@hilbertinc.com> ---
I am not sure what you are needing. I am using the connection pool with
functional programming, not in a serlvet container as the normal use case would
expect. As a result, I don't always easily have the reference to the
connection, unless I start passing it through the monad, which is possible, I
suppose.
I guess my expectation is that a proper implementation of a proxy design
pattern would implement all of the use cases of the proxy. Or to put it
another way, if 48392 was accepted as a bug, this should be, too.
I took a second look at the code and my proposed solution might leak resources,
so I updated the ConnectionPool class to check in the "returnConnection"
method.
What are our next steps, here?
--
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