Bug #66430 | setCatalog on connection leaves ServerPreparedStatement cache for old catalog | ||
---|---|---|---|
Submitted: | 17 Aug 2012 12:09 | Modified: | 18 Apr 2017 23:44 |
Reporter: | Pete Hendry | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | Connector / J | Severity: | S2 (Serious) |
Version: | 5.1.21 | OS: | Any |
Assigned to: | Filipe Silva | CPU Architecture: | Any |
[17 Aug 2012 12:09]
Pete Hendry
[17 Aug 2012 13:32]
Mark Matthews
Are you actually using the prepared statement cache?
[17 Aug 2012 22:15]
Pete Hendry
Yes. I debugged through the code and we are getting a statement out of the cache within ConnectionImpl. I can see the statement has database set to a previous catalog and is an instance of ServerPreparedStatement. Why do you ask? It shouldn't really matter as it seems like this is a pretty obvious bug with the key being the SQL and the value being hardwired to a specific database/catalog - it will obviously be a problem if you change catalog and use the same SQL on the new catalog will it not?
[24 Apr 2013 10:48]
Alexander Soklakov
Hi Pete, Verified by code review.
[18 Apr 2017 23:44]
Daniel So
Posted by developer: Added the following entry to the Connector/J 5.1.42 changelog: "After a connection had already switched catalog with setCatalog(), cached data from the old catalog was returned for a reused server-side prepared statement. With this fix, the cache of a server-side prepared statement cache now includes the catalog in its key to avoid wrong cache hits when the statement is reused on another catalog."
[8 Feb 2018 16:28]
Filipe Silva
Duplicate Bug#89552 filed after this fix.