[
https://issues.apache.org/jira/browse/DBCP-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13968045#comment-13968045
]
Phil Steitz commented on DBCP-415:
----------------------------------
@Sebb - I don't think that is actually a problem. Only one thread at a time
should have access to a given PoolingConnection at a time (else we have a
[pool] problem, which I first thought this might be, but now think it is not).
As long as clients adhere to the pool contract (which I am pretty sure DBCP
does and I know the test code does from DBCP standpoint - no retained
references / use after connection close), there will be no concurrent access to
a single PoolingConnection. In addition to that protection, the
PoolalePreparedStatements are accessed only through their PooledObject wrappers
in the GKOP owned by the PoolingConnection that they belong to. I could be
wrong, but I am pretty sure that the problem here is the "back door" access to
the DelegatingStatement via the finalizer. I am -0 to the volatile changes, OK
if they can be shown to have zero performance impact.
> 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)
