[
https://issues.apache.org/jira/browse/DBCP-566?focusedWorklogId=454660&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-454660
]
ASF GitHub Bot logged work on DBCP-566:
---------------------------------------
Author: ASF GitHub Bot
Created on: 05/Jul/20 22:57
Start Date: 05/Jul/20 22:57
Worklog Time Spent: 10m
Work Description: psteitz commented on a change in pull request #42:
URL: https://github.com/apache/commons-dbcp/pull/42#discussion_r449927856
##########
File path: src/main/java/org/apache/commons/dbcp2/PoolableConnection.java
##########
@@ -124,6 +124,9 @@ public PoolableConnection(final Connection conn, final
ObjectPool<PoolableConnec
protected void passivate() throws SQLException {
super.passivate();
setClosedInternal(true);
+ if (getDelegateInternal() instanceof PoolingConnection) {
+ ((PoolingConnection)
getDelegateInternal()).connectionReturnedToPool();
+ }
}
Review comment:
This is a little awkward. I see now how my initial idea does not work.
Implementing passivate in PoolingConnection would do nothing as it would never
be called. I was tempted to recommend that we change PoolableConnection
passivate to cascade to its delegate, but the problem is the delegate could
just be a Connection (physical). So no way around this that I can see.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 454660)
Time Spent: 50m (was: 40m)
> Clear PreparedStatement pool when connection is returned to the pool
> --------------------------------------------------------------------
>
> Key: DBCP-566
> URL: https://issues.apache.org/jira/browse/DBCP-566
> Project: Commons DBCP
> Issue Type: New Feature
> Reporter: Robert Paschek
> Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> With the current configuration option poolPreparedStatements true the
> statements are held open for the lifetime of the connection. This results in
> cursors being open and locks in the database for a long time, which could
> cause problems with administrative tasks in the database.
> There should be an additional configuration clearStatementPoolOnReturn. When
> set to true, the pool will be cleared and the statements closed when the
> connection is returned to the pool. Default can be false to retain the
> current behaviour.
> With this the application can still benefit from the Statement-cache in mass
> operations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
