A co-worker and I have been having a discussion about objects that get read from external (not in vm) caches. Both of us are confusing ourselves.

So the example is this. I load an Entity from a Session at the start of a conversation. I serialize the object to an external cache (ie, memcache d) after the session the is closed. A long while later that same object is looked up in the cache and is to be edited by the application. If we are to attach it to the Session, should we use update() or persist()?

I always thought that persist works like save() and correlates to a INSERT statment in the db. Is that true?

can I call update() on an object that has never been attached to a session (if my application knows that there is an actual entity who's id is equal to my object that I copied from an external (not hibernate-based store)?



Hibernate version:3.2

Neither. Use replicate or merge.


Yep.


Nope, but both merge and replicate support that functionality.

Just a question on this: the latest (3.2.1) hibernate documentation says, in section 10.6:



So the suggestion is to use update() normally, not merge().
Using merge() might bear the risk that you have accidentally loaded the original instance from the database, and now you have confustion since you have your detached (possibly modified) instance and a fresh attached instance. This would most probably be a programming error, and when using merge() such an error would go undetected.

Why do you think one should use merge() instead of update()?

I think I agree. I'm doing a
}

I can't guarantee in the scope of my method that the object to be used in the session is really in the database because I'm useing ids generated by hibernate.

Just to be clear: using persist for an object that I know to exsist in the database doesn't make sense, right? I can call update() with an object that has never been persisted to a Session (for example if I find entity data that is in my memcached that is valid and (for example) my JVM has been restarted since the conversation started...

thanks for all the input

If you're not sure if you should use update() or save(), use session.saveOrUpdate().

If you accidentally loaded the original instance, then your unit tests need updating. Much more likely, you either didn't load the original instance, or you loaded it to do some manual checking against its current (in DB) state. In both of these cases, you should use merge(), because you're sure that the object that you're saving has the correct values in it, irrespective of any other copies of the same entity that may be laying around. If you have more than one copy of an entity that might be correct, and you can't tell which one is correct, then you need more unit tests.

You can use merge() any time you can use update(), and also in some other cases. The only time that I can think of that you'd want to use update() when merge() would work, is when you want hibernate to tell you that you shouldn't be saving a certain copy of an entity, because there's some other object that should be saved instead. In this case.. why didn't you know that yourself already?

sorry for the confusion. I know for sure that save() shouldn't be used because I know that the object has a row in the db if the object is alive in my cache. transient or deleted objects will never be in the cache. But there could be objects in the cache that weren't ever in a persistant state since the JVM was restarted. I should say that the data (including id) coming out of the cache will be copied into new a pojo outside of hibernate. So, my confusiion is how to go about attaching that cache-constructed object back into a hibernate Session when it's time to edit it. Is that object considered to be detached and update() is ok. Or since that object was never persistant inside a Session, (no proxy bytecode ever created with it) is it ok to call persist() (my co-worker seems pretty sure that calling persist() is the right thing to do).

persist() makes transient object persistent. Transient objects are ones which don't have an equivalent row in the database. So persist() is not appropriate. You need to attach a detached object (even though this instance has never been attached, the entity has been). update() should work: merge() and replicate() definitely will. If you use update(), you may need to lock() the object first, I'm not sure.