h1. Query Cache should not be allowed for queries having Non Cacheable Query Spaces.
h2. Analysis:
* When query is cacheable i.e. 'org.hibernate.cacheable=true', and is having query spaces which are non cacheable, then this may lead to the well known *'N+1'* issue.
* I.e. the cached query result containing the * 'N' ids * , will further result in * N queries of 'findById' to the database * .
h2. Expectation:
* Query Cache should not be allowed for queries having Non Cacheable Query Spaces. Either throw an exception while loading the query, or rather ignore the query cache in this case.
* With this, even high number of puts to *'UpdateTimestampCache'* can be avoided. Which are originating from all the high number of transactional DMLs being executed to a query space which is non-cacheable.
h2. Possible Resolution: org.hibernate.loader.Loader.list method
* Maintain a set of cacheable 'query space (String)' - call it Metadata etc
* To the existing condition of checking whether cacheable or not, add the check of validating every corresponding query spaces in this Metadata set.
* If any of the query space is not in the cacheable metadata set, mark the final boolean variable 'cacheable' as false.
* So 'listIgnoreQueryCache' will be called rather than 'listUsingQueryCache' |
|
