Hibernate updates un-modified detached objects when we call saveOrUpdate method. I am using session-per-request-with-detached-objects pattern. (our application cannot use long term open sessions)

I have two POJO's A and B having one -to - many relationship
A - parent , B -children.

NOTE : On an average A contains atleast 500 B's in its Set.

On the UI side we will display sub set of of those 500B's based on a criteria.
User may edit some B's only at any time.

Intially we load object A along with associated B objects in one session
and display it on the UI.

user modifes some B objects on the UI. When user hits save on the UI,

on the server side we open a different session and call saveOrUpdate(A) , hiberante updates Object A table and also issues whole bunch of updates on B objects though only some of the B's are modified.

How to have updates only to modified objects at the time of calling saveOrUpdate method

I tried the following
a)select-before-update : causing too many sql to database
This works but now instead of updates I see a bunch of select stmt going to database

b) so I tried adding <cache usage="read-write"/> for both A and B (inside set element for B).
but select-before-update attribute bypasses secondary-level cache and queries the database.I Thougt by adding secondary-level cache , hiberante checks the state in the secondary cache than going to the database.

I am not sure how to tell hibernate always to check process-scope cache (secondary cache) instead of checking database for select-before-update
to verfiy the objects are dirty or not

I saw other articles suggesting to use custom persister for this, is there a better solution than this

thanks in advance for the response

My complete guess would be that you need to look at class EQUALITY for your B class.

That is Hibernate needs to be able to compare the detached instance and the one it will have to load from the database during the UI save cycle. It has to load it because it has to do a compare between it and the one the detached one.

I think this is to do with the Object.hashCode() and Object.equals(Object) functions, if you can make Hibernate see the detached on and the one it loaded from DB being equal it should not update the row.

Maybe this article will help http://www.hibernate.org/109.html

My 2 cents.

THanks for the reply.
But My hashcode and equals methods are working fine. since select-before-update attribute works which does not issue a update on unmodified objects but I see whole bunch of select's going to database to determine whether the object is dirty or not. I think the way hibernate checks this is by calling equals and hashcode methods after doing a select. But this attribute is causing too many select's no real benefit of stopping database round trips.

If my understanding is correct, the only way you can optimize away the SELECTs to check for dirty is if you can re-use the same session for the UI write cycle. Since it will have already seen and cached the values from the read.

I'm not very clued up on 2nd level caches, maybe they can help out in this situation.


How are you expecting Hibernate to know which items in the Set have been, added, removed, changed ? In your mind how does that algorithm work without calling a database ?

The open session is where object instance memory is kept, and you say you use a different one to saveOrUpdate().

The way I am expecting it to check dirty objects is by looking at secondary cache to see if the object is available and so calling equals method on the object to determine the object is dirty or not

As you know for new objects,it is just a matter of checking primary key
field (unsaved-value = null attribute which I think is the default). Hiberante
is already detecting this,and issuing inserts for this.

Basically I wanted hibernate to use secondary level cache (ehcache) as the basis of comparsion instead of going to the database for checking dirty/new objects.

Secondary cache is getting updated anyway when an object is ultimately
updated.

As I said in my note, A contains on an average 500 B's. If its going to
issue so many select's to database just to find an object is dirty or not
then these updates are no different than EJB2.0 enity beans. we have almost the same amount of overhead

You see what I am saying. As you know,In an enterprise application such as ours or for that matter any application, it is always better to reduce the round trips to database as much as possible.

The scenario which I am describing here is very common for many applications, and I was hoping for a way to tell hibernate to check secondary cache instead of going to database for dirty/new checks

Dirty checking is always done against the 1st level cache, not the second level cache.

You have two choices:

(1) (best) use an extended persistence context (long session)
(2) (also good) use merge() instead of saveOrUpdate()

Thanks Gavin
>>>> (1) (best) use an extended persistence context (long session)
This may not be an option for our application, because of scope of the application and the number of users and large number of objects we have.

>>>>>(2) (also good) use merge() instead of saveOrUpdate()

We are using hiberante 2.2 version and looks like merge() method is not
available in this version. Should I use lock + update call save round trips to database?

any ideas? and also why hibernate does not goto secondary cache (ehcache) when I say select-before-update for my classes. To my understanding secondary cache is process scoped cache.

lock(LockMode.None) + update is not doing any updates at all.