[
https://issues.apache.org/jira/browse/DBCP-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378236#comment-17378236
]
Shaktisinh Jhala commented on DBCP-579:
---------------------------------------
Hi [~ggregory]. Thanks for the details.
Yes, I can see that while creating the PoolableConnectionFactory in
BasicDataSource.createPoolableConnectionFactory, it sets the cacheState to the
newly created instance of PoolableConnectionFactory with its own instance
member cacheState which is initialized with value true so it is expected to
cache by default.
I can see you have added cachedSchema member variable in DelegatingConnection
class and it is being set in getSchema as well setSchema. So next time when
getSchema is called on same instance of DelegatingConnection, it will return
back the cachedSchema.
I will run the test with CPU profiling enabled with callCounting to see how
many times the actual implementation Jdbc41Bridge.getSchema is being called.
BTW, i could not understand your point "That, or, caching is enabled but still
shows up in the measurements because of the way the application makes use of
pools." We have simply configured BasicDatasource in our spring context xml
file. Can you pl elaborate on this please.
> 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)
