Clear query cache during checkin, instead of an execution callback #26909
It doesn't make sense for the query cache to persist while a connection moves through the pool and is assigned to a new thread. [Samuel Cochran & Matthew Draper]
Wonderful, thanks @matthewd. Love how that test has turned out — I wasn't familiar with Concurrent::Events.
Would be nice not to touch the connection until it is required. Could enabling the query cache be an after checkout callback?
If so, the only bits left in the QueryCache concern's executor complete method is connection pool cleanup, nothing to do with the query cache.
If we enable the query cache in an after checkout callback, the cache will be enabled in several situations where it's not currently active. The ones I can think of are:
None of these changes are necessarily bad (I would love for the multiple pools one to happen!) but it's worth carefully considering whether apps could break if they don't expect the caching behaviour.
In contrast, I think it's extremely unlikely that this change could break any application code - so I think we should ship this and decide whether to change how the cache is enabled separately.