[
https://issues.apache.org/jira/browse/DBCP-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969231#comment-13969231
]
Phil Steitz commented on DBCP-415:
----------------------------------
Returning to the actual issue here, I am not sure now I really get the need for
the finalizer as described in the javadoc for DelegatingStatement#finalize.
When statement pooling is enabled the PoolableXxxStatements are strongly held
by the statement pool in the allObjects maps under their keys, so I don't see
how they end up garbage collected. On the other hand, I can see why the close
needs to be there on finalization if we want the auto-cleanup behavior asked
for in POOL-180. Unfortunately, IIUC what is going on here, the change that I
suggested above will not trigger the close-on-GC behavior in general. If we
want both, we probably need to explicitly guard against the case where a
DelegatingStatement is wrapped by a PoolableXxxStatement. Could be I am
missing something about the issue and fix for POOL-180.
> Pooled PreparedStatements may be closed when accessed
> -----------------------------------------------------
>
> Key: DBCP-415
> URL: https://issues.apache.org/jira/browse/DBCP-415
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Phil Steitz
>
> Under high concurrency, connections using pooled PreparedStatements may
> encounter SQLExceptions with messages of the form
> "org.apache.commons.dbcp2.PoolablePreparedStatement with address: 'quoted
> SQL' is closed."
--
This message was sent by Atlassian JIRA
(v6.2#6252)
