Sorry for the noise - I misread the error.  I missed that it was doing an
invalidation (update) in the middle of the test as well.

That failure is valid after all.  Somehow the query execution count is
getting out of sync with miss/put counts.  Those values should always be
equal.  I'll have to track down where/why execution count is not

On Wed, Mar 7, 2018 at 11:44 AM andrea boriero <> wrote:

> is the first check assertEquals( qs.getCacheHitCount(), 0 ); ?
> On 7 March 2018 at 17:12, Steve Ebersole <> 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 mailing list

Reply via email to