Hi, I'm a newbie to Hibernate, so I'm not sure if I have all the fundamental concepts right, but I did try to read as much documentation as I could that seemed relevant to my problem.

My understanding is that when you start a new session and perform an save a new model object (i.e. change an object from being transient to persistent), the object is first stored in some sort of cache managed by Hibernate. It is only when flush() is called on the session (either manually or automatically) that the changes made are actually sent to the database.

I am in a situation where I would like to enable the user to create and "persist" objects into Hibernate's cache, but not immediately send these changes to the database, so I've set the flushmode to "Never", and plan on calling flush() manually upon the user's request.

However, I would like for SELECT queries perform by the user to take into account the objects in the cache in addition to the objects in the database, as opposed to only the objects in the database.

I've made sure that the session object the user is using to do the SELECT is the same as the one used to do the UPDATE, so I'd imagine that they would both be using the same cache. However, it looks like the SELECT queries don't "see" the changes made by the UPDATE until I've called flush().

Is there a simple way within Hibernate to get the behaviour I want? Our alternative plan is to implement our own custom caching layer on top of Hibernate and to intercept queries and inject our cached objects into the result, but obviously if there was a solution already implemented in Hibernate, we'd like to use that instead.

The Session cache provides repeatable read for entity objects. Not for scalar values, and not for persistent-but-not-flushed-objects if they have no entity identity (if they have been never in the database before).

Sounds like you mean "cache" as in "session cache", but if it's the second-level cache you're talking about, Query.iterate() method takes advantage of it by retrieving only identifiers first, then session/second-level cache, and finally the database.

jd

I wasn't aware that there was more than one cache, but yes, it sounds like the "Session cache" is what I was talking about.

And yes, it's newly persisted objects that haven't been flushed and have never been in the database before that I want to be query-able.

So what I want is not directly possible in Hibernate?