[
https://issues.apache.org/jira/browse/DBCP-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378031#comment-17378031
]
Gary D. Gregory edited comment on DBCP-579 at 7/9/21, 1:17 PM:
---------------------------------------------------------------
Hi [~sjhala]
Thank you for your update.
I can't explain the class file timestamps oddity within the jar. I just built
and deployed another SNAPSHOT jar to the snapshot repository and that jar's
class files also have the odd timestamps.
The next step is to debug your application from connection pool creation and
make sure caching gets propagated all the way down to the
{{org.apache.commons.dbcp2.DelegatingConnection.cacheState}}.
With caching enabled, which it should be by default in
{{org.apache.commons.dbcp2.BasicDataSource.cacheState}}, I would expect
{{org.apache.commons.dbcp2.DelegatingConnection.getSchema()}} to call
{{org.apache.commons.dbcp2.Jdbc41Bridge.getSchema(Connection)}} only once for a
given {{DelegatingConnection}} instance. That one call could take a while and
still show up in your measurements but it should only happen once per instance.
It is possible that your specific configuration does not use caching at the
level of {{DelegatingConnection}} somehow. That, or, caching is enabled but
still shows up in the measurements because of the way the application makes use
of pools.
was (Author: garydgregory):
I can't explain the class file timestamps. I just built and deployed another
SNAPSHOT and that jar's class files also have the odd timestamp.
The next step is to debug your application from connection pool creation and
make sure caching get propagated all the way down to the
{{org.apache.commons.dbcp2.DelegatingConnection.cacheState}}.
> Performance of DelegatingConnection.prepareStatement(String) regressed
> enormously in 2.8.0 compared to 1.4
> ----------------------------------------------------------------------------------------------------------
>
> Key: DBCP-579
> URL: https://issues.apache.org/jira/browse/DBCP-579
> Project: Commons DBCP
> Issue Type: Bug
> Affects Versions: 2.8.0
> Environment: OS: Windows Server 2008 R2 Enterprise
> Java: Open JDK 12.0.1
> DB: Microsoft SQL Server 2012 - 11.0.5058.0 (X64)
> Reporter: Shaktisinh Jhala
> Priority: Major
> Attachments: DBCP_v1.4.jpg, DBCP_v2.8.0.jpg,
> WithPrivateJarFrom2.9.0.jpg
>
>
> We recently upgraded the commons DBCP from version 1.4 to latest version
> 2.8.0. After the upgrade, we observed significant degradation in our use
> case. After the analysis it was found that the performance of
> DelegatingConnection.prepareStatement(String) is regressed in version 2.8.0
> enormously compared to 1.4 where the approx time taken in 2.8.0 is 7400
> seconds compared to approx 183 sec in 1.4.
> Looking at the Yourkit snapshot, it is observed that the newly added call
> PoolingConnection.createKey(String) in the method
> PoolingConnection.prepareStatement(String) is the major contributor for this
> regression.
>
> We took multiple snapshot and in all these snapshot we observed the
> regression. So it was not intermittent. Also, we observed this with both the
> our DBs (MS SQL server and PostgreSQL)
>
> Please find attached the screenshot of YourKit Snapshot showing the Merged
> Callees of DelegatingConnection.prepareStatement(String) taken for MS SQL
> server with commons DBCP version 1.4 and version 2.8 for further details.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
