Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
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.
Attachments
1
14 Mar 2014, 02:57 AM
Activity
Brett MeyerJuly 8, 2014 at 3:11 PM
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!
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.
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.