[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