As per the the Hibernate documentation, Query.setCacheMode() accepts an enum value from CacheMode. CacheMode.IGNORE is specified as: "The session will never interact with the cache, except to invalidate cache items when updates occur."

When using this setting to attempt to bypass the cache, it is effectively ignored; stale data is returned, rather than current the data in the database.

A brief and uninformed inspection of the code indicates that while an attempt is made to honor the cache setting, after the generated SQL for the particular dialect is executed, an attempt is made to match the key from the result against a key in the persistence context; if a match is found, the cached instance from the persistence context is used to avoid the overhead of "hydrating".

The attached testcase contains a small Gradle project with a single JUnit test demonstrating the behavior. The test is self-contained and uses "raw" JDBC to manipulate the database around the work done with the Session. The problem is exhibited on all 3.6.* versions released to date; I have not tried older versions, nor the 4.* line.

Note: This is likely to be closely related to HHH-9045, which describes a very similar problem when using Hibernate as a JPA provider.