[hibernate-dev] Self sanity check - caching and stats changes - invalidated query cache results

andrea boriero andrea at hibernate.org
Wed Mar 7 12:43:48 EST 2018


is the first check assertEquals( qs.getCacheHitCount(), 0 ); ?

On 7 March 2018 at 17:12, Steve Ebersole <steve at hibernate.org> wrote:

> I am trying to finish up these caching and stats related changes, but am
> currently fighting a few remaining test failures.  In my initial
> investigation IMO some of these tests are wrong, but hoped someone(s) else
> could check may expectation/belief.  E.g. have a look at
> `org.hibernate.test.querycache.QueryCacheTest#testQueryCacheInvalidation`.
> It seems to me that the assertions using stats regarding cache hit/miss/put
> counts are wrong right from the very beginning.
>
> But I was hoping to get to a point where absolutely zero test changes were
> necessary.  So was hoping to get others opinions.
>
> The test issues a number of cacheable queries.  The first time happens in a
> Session in which the just queried entity is then inserted.  This insertion
> ought to (validly) trigger an invalidation of these already cached query
> results.  However the test assertions assert the opposite - that the
> insertion not invalidate the cache.  Possibly the old code handle this
> specially (cache hit + "invalidated results") - I still need to dig into
> the old code to see if that is true.  But to me, anyway, that seems wrong.
> Unless we add a new stat collection for query caching for the number of
> times we also considered cached results invalidated due to "update
> timestamps".
>
> WDYT?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


More information about the hibernate-dev mailing list