Bug 63320 - StatementCache interceptor does not cache statements that return values in dedicated columns
Summary: StatementCache interceptor does not cache statements that return values in de...
Status: RESOLVED FIXED
Alias: None
Product: Tomcat Modules
Classification: Unclassified
Component: jdbc-pool (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 major (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-05 15:59 UTC by Ronny Schuetz
Modified: 2019-04-09 07:28 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ronny Schuetz 2019-04-05 15:59:09 UTC
The StatementCache interceptor does not cache calls to 

 Connection#prepareStatement(String, String[])

and most likely 

 Connection#prepareStatement(String, int[])

The reason is CacheKey#equals and #hashCode, that use Array#equals resp. #hashCode when processing the args array, which does not work correctly as the args array contains a nested array in this case. Switching to Arrays#deepEquals resp. #deepHashCode fixes the issue.

We need to use the StatementCache together with Spring, as Springs JdbcTemplate creates a new statement for each call and Oracle looks up the type of the return values for each created statement, which got dramatically slower with Oracle 18.
Comment 1 Ronny Schuetz 2019-04-08 08:08:57 UTC
Just for clarification, as the description might be a bit misleading: The results get added to the internal map, but cannot be retrieved anymore due to the broken CacheKey implementation.
Comment 2 Keiichi Fujino 2019-04-09 07:28:34 UTC
Thanks for the report.
The fix will be in :
- 9.0.x for 9.0.18 onwards
- 8.5.x for 8.5.40 onwards
- 7.0.x for 7.0.94 onwards