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.
Windows, Linux; Oracle, H2
In an effort to clean up, in bulk, tickets that are most likely out of date, we're transitioning all ORM 3 tickets to an "Awaiting Test Case" state. Please see http://in.relation.to/Bloggers/HibernateORMJIRAPoliciesAndCleanUpTactics for more information.
If this is still a legitimate bug in ORM 4, please provide either a test case that reproduces it or enough detail (entities, mappings, snippets, etc.) to show that it still fails on 4. If nothing is received within 3 months or so, we'll be automatically closing them.
Bulk rejecting stale issues. If this is still a legitimate issue on ORM 4, feel free to comment and attach a test case. I'll address responses case-by-case. Thanks!