Hi everyone. I have been using Hibernate for about six months with no problems, but I seem to very stumped about a core concept. What is the purpose behind calling save() or saveOrUpdate()...isn't the actually saving happening when I do a flush? I didn't know about flush() until just today so I am guessing.

The problem came became aparent today when I discovered that a process I am running in a transaction does not need save() called upon it to actually do a save. From there I went back and reread all the documentation and it appears that you only need to call save() if not in a transaction and then the saving to the database really happens when you flush(). Is that confusing to anyone else? What is the purpose behind save()? I would expect when I call save it would actually do the save right then.

I use the spring framework for all but this one project and when I call save using spring it actually does do the save so I guess behind the scenes it calls flush?

I went and grabbed Oreilly's Hibernate Developers Notebook and he thinks that the ability to not save persistent objects when calling save() is a bug and recommends always doing transaction processing. Apparently he is not clear about calling save() vs flush() either...

If someone could shed some light I would be eternally grateful!!

Before hibernate 2.0 was released; it did not detect if a field was modified. Hence you had to call save so this operation is added to the current unit-or-work. Now (post 2.0) if in your in session and you make a change to a field, this will be added to the unit-of-work since hibernate can detect that it is dirty. Flush forces the updates that are, queued in the unit-of-work, to be sent to the database, eg, you will see the SQLs output if enabled. From there the Transaction will either commit those changes or rollback. Note: depending on your transaction setup flush will be called as a part of the commit. In CMT environment flush needs to be called.

I think that makes sense, but you seem to be implying that I need to run in a transactional process also. What if I am not running in a transactional process. Should I not be able to load an object, modify it, and then flush those changes without ever calling save()? Under my new understanding I would think that is the case. It does not seem to work like that at all. Its the lack of consistency between running with and without a transactional process that is throwing me off.

You also said...Note: depending on your transaction setup. Could you elaborate on what you mean. Is there more than one way to set up a transaction?

This is not correct. Hibernate always did automatic dirty checking.

save() makes a new instance persistent, it is not needed for updates!

--> save() makes a new instance persistent, it is not needed for updates!

And that makes sense that save() will make a new instance persistent. Thanks for the clarity. Could you be that blunt about update, and saveOrUpdate...are they ever needed? What is the point of having them if flush() is doing the work?

It just does not seem to work like that though, at least when using Spring. At work we tested an object by trying to load it, modify it, and then flush it, but it did not save (persist) anything and that has become the core source of the confusion... It worked fine running under a transaction though.

And then I picked up the Hibernate Developers Handbook and he says that "Analyzing the SQL emitted by Hibernate revealed that even though I didn't request a transaction, auto-commit was being turned off, so my changes were getting rolled back when the application ended. So, for now its always necessary to use explicit transactions in your code, a good habit in any case." It was discouraging reading that in an authored book...I cannot wait for the other book to come out in August!!

Doh - sorry Gavin - I read my own reply and see the obvious mistakes - I was thinking updates - sorry if my attempt to be clear was not helpful. Oh well, I'll have another shot.

OK saveOrUpdate uses the id's state to know what operation to perform, eg, if the id is null and the mapping document indicates null means not-saved then a call to saveOrUpdate will perform a save. If, as in this example, the Id is not-null then an update will be performed. This is a convenice method so you don't need to know the current persisted state of the domain object before the presistence operation occurs. Can be very helpful if your using transient objects in your application.

To clarify your update observation, you should always use transactions even for read only operations. The database always does anyway as it need to maintain the various lock states so your data stays consistent. Spring has excellent support for them so your in good position.

WHAT?! This is plain wrong. I guess I have to get a copy of this book.

OK, my world makes sense again. I came into work and retested things based on my new understanding...and it all works like it is supposed to. When dealing with apps that use Spring, do not Use Spring, and/or working with transactions vs nontransactions it all gets a little confusing...

To say that an object is transient if not coming directly from Hibernate and persistent if coming from Hibernate makes sense now. Furthermore, I can see that the only way Hibernate would know about an object that is transient would be to do something like a save(), update(), or saveOrUpdate() to make it persistent. It really isn't obvious what flush() does when you first start working with Hibernate, although I can see that it is to "flush()" data to the database. Its hard to get away from thinking that save() does, well, save data right then. It is further confusing when you find out that save(), update(), and saveOrUpdate() also do a flush() automatically in Spring so it appears that save() really saves.

I am just reiterating so I hope others find it useful.

I thank you for your help!!

If you look at the new EJB3 draft, you can see different names for those methods. This will make it much easier to understand the states of the objects.