[hibernate-dev] Negative value returned by BaseRegion.getTimeOut(); Inconsistent UpdateTimestamps cache hit/put counts

[Gail Badner]

I'm looking into the CMTTest.testConcurrentCachedDirtyQueries() failure, which involves an unexpected second-level cache hit. This test is skipped when using H2, so this failure was overlooked until recently. 

It turns out that org.hibernate.testing.cache.BaseRegion.getTimeout() returns Timestamper.ONE_MS * 600000.

Since Timestamper.ONE_MS is 4095, the product is 2457000000, which overflows the int return value, resulting in a negative timeout being returned. Because of this, the update timestamp ends up being before the cached query result timestamp. Hibernate assumes (erroneously) that the cached query results are up-to-date.

Changing BaseRegion.getTimeout() to return Timestamper.ONE_MS * 60000 gets past that assertion. I should also mention that this change causes org.hibernate.ejb.test.EntityManagerTest and org.hibernate.ejb.test.packaging.PackagedEntityManagerTest to fail on H2 because there are fewer than expected second-level cache hits. My guess is that the lower number is really correct, but I haven't looked into it.

Later assertions in CMTTest.testConcurrentCachedDirtyQueries() involving UpdateTimestamps cache hit/put counts fail. In fact, none of the expected values for the UpdateTimestamps cache hit/put counts in that test match the actual values, and I'm seeing different counts depending on whether the full test suite is run vs the failing test method alone.

As an example, this assertion is on line 307:

assertEquals( sessionFactory().getStatistics().getUpdateTimestampsCacheHitCount(), 4 );
(Yes, I know the expected value is supposed to be first.)

The expected value is 4.
The actual value when running/debugging the full test in Intellij is 2.
The actual value when running/debugginb the CMTTest.testConcurrentCachedDirtyQueries() alone in Intellij is 1.

I see that CMTTest.getCacheConcurrencyStrategy() returns "transactional", which gets mapped to org.hibernate.testing.cache.NonstrictReadWriteEntityRegionAccessStrategy (which is obviously not transactional) by org.hibernate.testing.cache.EntityRegionImpl.

Was a different cache used when this test was written? Could that be a reason why the counts are off?

Does anyone know if this test ever passed on the other dialects?

Does anyone have any insight into what is going on here?

Thanks,
Gail