Hibernate version: 3.0

I'm verifying an hibernate behavior that I don't think to be appropriate, but maybe there's some configuration that I don't realize. When an object is loaded (session.load()) this object is stored on session cache. If I do some modification on object, and after load it again the hibernate updates this object against database (and don't make an other select, because the object is in cache). I think this behavior is undesired because if I reload the object I don't want the modifications anymore and I wish discard it. So, in this case why hibernate don't invalidate the cache and reload my object? If I want save the update, I'll call session.update(). I still want local cache for this object, then I don't want to use session.evict().

Some clues on this?

Hi,

I believe that the behavior you are describing cannot be parametrized and is intended to work this way. Maybe what is confusing you is the name LOAD, which sounds like it retrieves data directly from the database.

The cache system is meant to prevent Hibernate from constantly hitting the database. There would be no point in having it constantly check if data is outdated. You would face the opposite problem of erasing changes to your entities in long transactions or long sessions.

Maybe you can achieve what you want by using session.refresh(). It will reload the state from the database. But I don't understand why you do not want to use session.evict() if the object is not valid anymore. You might as well get rid of it and it will be reloaded on demand.

Let me know if refresh() does it for you :)

Regards,
Vincent.

No. I know that load can (and must) hit the cache when needed. What I'm saying is that when I make an LOAD and the object on cache was modified, then the object must be retrieved again from database and refresh the cache. I think that hibernate don't have to UPDATE this object without an explicit instruction to do this, like session.update().

Session.refresh() can help, if my client application have access to persistence level. This is not the case. I have one façade level taking care of persistence. To use refresh, I need to know if the object was modified before refresh it. If the object wasn't modified, then cache must be used.

The scenario is: the user can make modifications direct on objects previously loaded (most of then are in collections, actually) After make this modifications he can save or not. If choose not save, I have to reload the previous state of these objects.

Now, I understand your problem.

Could you describe the scope of your session? Your facade opens a new Session whenever a client issues a request, or do you keep it open for a longer time?

Of course I can. I using a ThreadLocal session pattern on a stateless session bean. Each client request reconnect the session, start transaction and commit/rollback it. I know that are some kind of trick to lead with this situation (I'm thinking to use an boolean attribute in my pojos), but I think that hibernate don't have to do this... some possibility the guys change this? (Gavin?)

Hi. I make some mistakes here. First, the problem wasn't with get or load, but with commit. Second, my session was open between two requests, so the commit make the changes in the cache mades in previous get.

I realize this because I testing not on facade, but on local object, for debugging purposes. On facade, the session will be dropped then this not occurs.

Sorry by the mistake....