11:12 a.m.
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?
11:43 a.m.
is the first check assertEquals( qs.getCacheHitCount(), 0 ); ?
On 7 March 2018 at 17:12, Steve Ebersole <steve(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:48 a.m.
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
incremented.
On Wed, Mar 7, 2018 at 11:44 AM andrea boriero <andrea(a)hibernate.org> wrote:
is the first check assertEquals( qs.getCacheHitCount(), 0 ); ?
On 7 March 2018 at 17:12, Steve Ebersole <steve(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
2506
days inactive
2506
days old
2 comments
2 participants
participants (2)
-
andrea boriero -
Steve Ebersole