1

I came across this explanation when I was trying to understand between Hibernate Save and persist:

persist() is well defined. It makes a transient instance persistent. However, it doesn't guarantee that the identifier value will be assigned to the persistent instance immediately, the assignment might happen at flush time. The spec doesn't say that, which is the problem I have with persist().

persist() also guarantees that it will not execute an INSERT statement if it is called outside of transaction boundaries. This is useful in long-running conversations with an extended Session/persistence context.

A method like persist() is required.

save() does not guarantee the same, it returns an identifier, and if an INSERT has to be executed to get the identifier (e.g. "identity" generator, not "sequence"), this INSERT happens immediately, no matter if you are inside or outside of a transaction. This is not good in a long-running conversation with an extended Session/persistence context.

Can you please help me in understanding the lines for persist that says:

persist() also guarantees that it will not execute an INSERT statement if it is called outside of transaction boundaries. This is useful in long-running conversations with an extended Session/persistence context.

What are the transaction boundaries here? and what are the long-running conversations? what is extended Session/persistence context means?

Also for save method:

this INSERT happens immediately, no matter if you are inside or outside of a transaction. This is not good in a long-running conversation with an extended Session/persistence context.

I understand that we need not have statements like session.beginTransaction() and session.getTransaction().commt() if we are using save method in my program for saving an object. Please let me know if the statement says the same thing here. So how is this useful in long running conversations?

I am new to hibernate and finding it difficulty to understand the differences, can you please help me in understanding the differences.

Chaitanya
  • 15,403
  • 35
  • 96
  • 137
  • Related Questions: http://stackoverflow.com/questions/5862680/whats-the-advantage-of-persist-vs-save-in-hibernate and http://stackoverflow.com/questions/8097679/whats-the-difference-between-persist-and-save-in-hibernate – reto Nov 15 '13 at 08:39

4 Answers4

6

Your question relates to the Open Session in View pattern Hibernate implements.

The idea is that you might have an atomic unit of work in a web application that needs to run throughout a particular process. Imagine ordering food online. You sign in on one page, choose pizza and toppings on the next page, add dessert on the next page, add drinks on the next page, and pay on the last page. You want that whole process to be a single unit of work.

So the Hibernate Session needs to be opened at the beginning of that unit of work and closed at the end--either manually or through some kind of container management.

Calling persist during that conversation will not result in any inserts of data, but it will make a detached entity persistent. Hibernate will "keep a record" of all inserts to be made and then flush them at the end of the conversation.

Meanwhile save does the insert immediately and gives your entity an id from the database. This isn't good during a long-running conversation because you want your database operations to be atomic--all or nothing. Weird things like multiple inserts of the same data could occur.

Hope that helps.

Vidya
  • 29,932
  • 7
  • 42
  • 70
  • So where would you store the Hibernate Session between different requests? Would you put it in the HttpSession? – Kevin Bowersox Oct 29 '14 at 00:13
  • Your second paragraph is describing something like a seam conversation, which is totally separate from open-session-in-view. transactions should almost never be held open during user-think time. i think you need a better example. – Nathan Hughes Apr 20 '15 at 20:21
  • It's true my example could *also* describe a Seam conversation, at least back in 2012 when Seam was still a thing. You seem to be confusing the different levels of abstraction--a persistence concern with Hibernate and a middleware concern with Seam. The two aren't mutually exclusive, so the example could describe both things simultaneously. Even still, I have no doubt there are better examples. But I think it would be much more constructive and interesting to the OP and others for you to actually provide a better example than merely offer the possibility of its existence. – Vidya Apr 21 '15 at 00:16
1

The save() method can return that primary key id value which is generated by hibernate and we can see it by

long s = session.save(k);

In this same case, persist() will never give any value back to the client, hope you are clear.

So persist() method guarantees that it will not execute an INSERT statement if it is called outside of transaction boundaries since there is no need to get id after persisting an object.

Whereas the save() method does not guarantee the same, since it need to returns an identifier (probably primary key id).

An INSERT has to be executed to get the identifier (e.g. "identity" generator), So, this INSERT happens immediately with save(), no matter if you are inside or outside of a transaction.

Sandhu Santhakumar
  • 1,678
  • 1
  • 13
  • 24
1

One of the key difference between save and persist methods are depends on ID generation strategies. Basically save() method will return the value(id) back to the client and persist() method will not..

1) In a case where you let your ORM engine generates ID for you and in those cases you can use save().Reason is simple "Hibernate giving you the opportunity to get to know what ID it has generated/used to persist your object "

2) In a case where your have generated your id by yourself (assigned ID generation strategy) and passing it to ORM engine to use the same to persist your object.In such cases persist() will be appropriate .

click here

As I said

"It depends on ID generation strategies"

Cheers!

Balaji Reddy
  • 5,576
  • 3
  • 36
  • 47
0

As the method name suggests, hibernate save() can be used to save entity to database. We can invoke this method outside a transaction. If we use this without transaction and we have cascading between entities, then only the primary entity gets saved unless we flush the session

Hibernate persist is similar to save (with transaction) and it adds the entity object to the persistent context, so any further changes are tracked. If the object properties are changed before the transaction is committed or session is flushed, it will also be saved into database. Also, we can use persist() method only within the boundary of a transaction, so it’s safe and takes care of any cascaded objects. Finally, persist doesn’t return anything so we need to use the persisted object to get the generated identifier value.

Rohit Goyal
  • 550
  • 8
  • 9