UpdateTimestampCache generates puts for non-cached regions

Description

I think we found a "major" flaw in the query-cache implementation with the result that we had to completely back off the caching of query results.

I will try to explain the usecase, but let me know if you need more information.

We have an entity Template which consists of around 100 objects. They change around once a month. We need to resolve them with a query as the internal ID is not meaningful in the resolution process. A perfect candidate you might say. So we activated query caching on that one resolution query.
That looked good in the beginning. Caching worked as expected and we got good results, at first.

Now we have another entity EndpointLog which logs each request to our webservice(s). This entity type gets updates a lot (40k/sec), so there is no entity- nor query-cache for this type.

During some performance tests we realized that the query cache got impacted alot even though we did not touch any template entities. Digging a little into the caching algorithm we found out that there was not only an UpdateTimestampCache entry for Template but also for EndpointLog.
I don't think this is the desired behavior as this results in unnecessary puts on the cache implementation where Hibernate could actually know that the query cache should only be done for a Template region.

The code in question, if I got it right, should be located in the ActionQueue.

1 2 3 4 5 6 7 8 // line 607 Hibernate version 5.2.10 if ( session.getFactory().getSessionFactoryOptions().isQueryCacheEnabled() ) { // Strictly speaking, only a subset of the list may have been processed if a RuntimeException occurs. // We still invalidate all spaces. I don't see this as a big deal - afterQuery all, RuntimeExceptions are // unexpected. Set<Serializable> propertySpaces = list.getQuerySpaces(); invalidateSpaces( propertySpaces.toArray( new Serializable[propertySpaces.size()] ) ); }

Shouldn't these QuerySpaces be filtered by spaces that actually had some cachable queries executed? I'm not sure how to implement that. Could the cachable query place some hints into the SessionFactory about which regions actually are cachable? That way the ActionQueue would only need to trigger timestamp updates on the template region in our case, resulting in actual cache updates a magnitude smaller then currently.

Once we deactivated the query cache entirely we got far better results. I strongly believe that this relates to the enormous amount of updates of "non-cacheable-regions". It would be very interesting to see if this is the case. I would be willing to help trying to filter these query spaces but would need some hints on where to hook in. ActionQueue looks like a good candidate, but I'd like to get some upfront insight before "wasting" some time on it

Environment

None

Status

Assignee

Unassigned

Reporter

ToDelete

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Priority

Critical
Configure