hibernate的各种保存方式的区别
Hibernate中的merge方法挺好用的。
官方文档的说明如下：
merge
Copy the state of the given object onto the persistent object with the same identifier. If there is no persistent instance currently associated with the session, it will be loaded. Return the persistent instance. If the given instance is unsaved, save a copy of and return it as a newly persistent instance. The given instance does not become associated with the session. This operation cascades to associated instances if the association is mapped with cascade="merge".
The semantics of this method are defined by JSR-220.
Parameters:
object - a detached instance with state to be copied
Returns:
an updated persistent instance
Throws:
HibernateException
有几种情况：
１．如果idertifier(以下简称为id)为空或不存在，则进行insert 动作
２．如果id存在，则进行update动作
至于会话层的就如文档上所说，不再多说。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
hibernate的update和merge
首先, merge作用大致相当于saveorupdate这个方法, 即有唯一性标识, 则运行save, 没有则运行update
下面来比较2者的区别, update(object), 方法运行后, object是持久化状态, 而Object obj = merge(object), 方法运行后, object是脱管状态, obj是持久化状态
最后比较2者的性能, 本人使用for循环测试10000次, merge: 150ms, update: 50ms, 显然update性能占优势.
所以, merge的用法应该是在需要返回被保存的对象时使用.
例子我就懒得贴了, 有兴趣的朋友可以自己测下, 我就只写结论了.
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
hibernate的各种保存方式的区别 (save,persist,update,saveOrUpdte,merge,flush,lock)等
hibernate的保存
hibernate对于对象的保存提供了太多的方法，他们之间有很多不同，这里细说一下，以便区别：
一、预备知识：
在所有之前，说明一下，对于hibernate，它的对象有三种状态，transient、persistent、detached
下边是常见的翻译办法：
transient：瞬态或者自由态
persistent：持久化状态
detached：脱管状态或者游离态
脱管状态的实例可以通过调用save()、persist()或者saveOrUpdate()方法进行持久化。
持久化实例可以通过调用 delete()变成脱管状态。通过get()或load()方法得到的实例都是持久化状态的。
脱管状态的实例可以通过调用 update()、saveOrUpdate()、lock()或者replicate()进行持久化。
游离或者自由状态下的实例可以通过调用merge()方法成为一个新的持久化实例。
save()和persist()将会引发SQL的INSERT，delete()会引发SQL的DELETE，
而 update()或merge()会引发SQL的UPDATE。对持久化（persistent）实例的修改在刷新提交的时候会被检测到，它也会引起 SQLUPDATE。saveOrUpdate()或者replicate()会引发SQLINSERT或者UPDATE
二、save 和update区别
把这一对放在第一位的原因是因为这一对是最常用的。
save的作用是把一个新的对象保存
update是把一个脱管状态的对象保存
三,update 和saveOrUpdate区别
这个是比较好理解的，顾名思义，saveOrUpdate基本上就是合成了save和update
引用hibernate reference中的一段话来解释他们的使用场合和区别
通常下面的场景会使用update()或saveOrUpdate()：
程序在第一个session中加载对象
该对象被传递到表现层
对象发生了一些改动
该对象被返回到业务逻辑层
程序调用第二个session的update()方法持久这些改动
saveOrUpdate()做下面的事:
如果对象已经在本session中持久化了，不做任何事
如果另一个与本session关联的对象拥有相同的持久化标识(identifier)，抛出一个异常
如果对象没有持久化标识(identifier)属性，对其调用save()
如果对象的持久标识(identifier)表明其是一个新实例化的对象，对其调用save()
如果对象是附带版本信息的（通过
否则update() 这个对象
四,persist和save区别
这个是最迷离的一对，表面上看起来使用哪个都行，在hibernate reference文档中也没有明确的区分他们.
这里给出一个明确的区分。（可以跟进src看一下，虽然实现步骤类似，但是还是有细微的差别）
这里参考http://opensource.atlassian.com/projects/hibernate/browse/HHH-1682中的一个说明：
---------------------------------------------------------------------------------
I found that a lot of people have the same doubt. To help to solve this issue
I'm quoting Christian Bauer:
"In case anybody finds this thread...
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."
---------------------------------------------------------------------------------
简单翻译一下上边的句子的主要内容：
1，persist把一个瞬态的实例持久化，但是并"不保证"标识符被立刻填入到持久化实例中，标识符的填入可能被推迟
到flush的时间。
2，persist" 保证"，当它在一个transaction外部被调用的时候并不触发一个Sql Insert，这个功能是很有用的，当我们通过继承Session/persistence context来封装一个长会话流程的时候，一个persist这样的函数是需要的。
3，save"不保证"第2条,它要返回标识符，所以它会立即执行Sql insert，不管是不是在transaction内部还是外部
五,saveOrUpdateCopy,merge和update区别
首先说明merge是用来代替saveOrUpdateCopy的，这个详细见这里
http://www.blogjava.net/dreamstone/archive/2007/07/28/133053.html
然后比较update和merge
update的作用上边说了，这里说一下merge的
如果session中存在相同持久化标识(identifier)的实例，用用户给出的对象的状态覆盖旧有的持久实例
如果session没有相应的持久实例，则尝试从数据库中加载，或创建新的持久化实例,最后返回该持久实例
用户给出的这个对象没有被关联到session上，它依旧是脱管的
重点是最后一句：
当我们使用update的时候，执行完成后，我们提供的对象A的状态变成持久化状态
但当我们使用merge的时候，执行完成，我们提供的对象A还是脱管状态，hibernate或者new了一个B，或者检索到一个持久对象B，并把我们提供的对象A的所有的值拷贝到这个B，执行完成后B是持久状态，而我们提供的A还是托管状态
六,flush和update区别
这两个的区别好理解
update操作的是在脱管状态的对象
而flush是操作的在持久状态的对象。
默认情况下，一个持久状态的对象是不需要update的，只要你更改了对象的值，等待hibernate flush就自动
保存到数据库了。hibernate flush发生再几种情况下：
1，调用某些查询的时候
2，transaction commit的时候
3，手动调用flush的时候
七,lock和update区别
update是把一个已经更改过的脱管状态的对象变成持久状态
lock是把一个没有更改过的脱管状态的对象变成持久状态
对应更改一个记录的内容，两个的操作不同：
update的操作步骤是：
（1）更改脱管的对象->调用update
lock的操作步骤是：
(2)调用lock把对象从脱管状态变成持久状态-->更改持久状态的对象的内容-->等待flush或者手动flush
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
先来点概念：
在Hibernate中，最核心的概念就是对PO的状态管理。一个PO有三种状态：
1、未被持久化的VO
此时就是一个内存对象VO，由JVM管理生命周期
2、已被持久化的PO，并且在Session生命周期内
此时映射数据库数据，由数据库管理生命周期
3、曾被持久化过，但现在和Session已经detached了，以VO的身份在运行
这种和Session已经detached的PO还能够进入另一个Session，继续进行PO状态管理，此时它就成为PO的第二种状态了。这种PO实际上是跨了Session进行了状态维护的。
在传统的JDO1.x中，PO只有前面两种状态，一个PO一旦脱离PM，就丧失了状态了，不再和数据库数据关联，成为一个纯粹的内存VO，它即使进入一个新的PM，也不能恢复它的状态了。
Hibernate强的地方就在于，一个PO脱离Session之后，还能保持状态，再进入一个新的Session之后，就恢复状态管理的能力，但此时状态管理需要使用session.update或者session.saveOrUpdate，这就是Hibernate Reference中提到的“requires a slightly different programming model ”
现在正式进入本话题：
简单的来说，update和saveOrUpdate是用来对跨Session的PO进行状态管理的。
假设你的PO不需要跨Session的话，那么就不需要用到，例如你打开一个Session，对PO进行操作，然后关闭，之后这个PO你也不会再用到了，那么就不需要用update。
因此，我们来看看上例：
Java代码
1. Foo foo=sess.load(Foo.class,id);;
2. foo.setXXX(xxx);;
3. sess.flush();;
4. sess.commit();;
Foo foo=sess.load(Foo.class,id);;
foo.setXXX(xxx);;
sess.flush();;
sess.commit();;
PO对象foo的操作都在一个Session生命周期内完成，因此不需要显式的进行sess.update(foo)这样的操作。Hibernate会自动监测到foo对象已经被修改过，因此就向数据库发送一个update的sql。当然如果你非要加上sess.update(foo)也不会错，只不过这样做没有任何必要。
而跨Session的意思就是说这个PO对象在Session关闭之后，你还把它当做一个VO来用，后来你在Session外面又修改了它的属性，然后你又想打开一个Session，把VO的属性修改保存到数据库里面，那么你就需要用update了。
Java代码
1. // in the first session
2. Cat cat = (Cat); firstSession.load(Cat.class, catId);;
3. Cat potentialMate = new Cat();;
4. firstSession.save(potentialMate);;
5.
6. // in a higher tier of the application
7. cat.setMate(potentialMate);;
8.
9. // later, in a new session
10. secondSession.update(cat);; // update cat
11. secondSession.update(mate);; // update mate
// in the first session
Cat cat = (Cat); firstSession.load(Cat.class, catId);;
Cat potentialMate = new Cat();;
firstSession.save(potentialMate);;
// in a higher tier of the application
cat.setMate(potentialMate);;
// later, in a new session
secondSession.update(cat);; // update cat
secondSession.update(mate);; // update mate
cat和mate对象是在第一个session中取得的，在第一个session关闭之后，他们就成了PO的第三种状态，和Session已经 detached的PO，此时他们的状态信息仍然被保留下来了。当他们进入第二个session之后，立刻就可以进行状态的更新。但是由于对cat的修改操作：cat.setMate(potentialMate); 是在Session外面进行的，Hibernate不可能知道cat对象已经被改过了，第二个Session并不知道这种修改，因此一定要显式的调用secondSession.update(cat); 通知Hibernate，cat对象已经修改了，你必须发送update的sql了。
所以update的作用就在于此，它只会被用于当一个PO对象跨Session进行状态同步的时候才需要写。而一个PO对象当它不需要跨Session进行状态管理的时候，是不需要写update的。
再谈谈saveOrUpdate的用场：
saveOrUpdate和update的区别就在于在跨Session的PO状态管理中，Hibernate对PO采取何种策略。
例如当你写一个DAOImpl的时候，让cat对象增加一个mate，如下定义：
Java代码
1. public void addMate(Cat cat, Mate mate); {
2. Session session = ...;
3. Transacton tx = ...;
4. session.update(cat);;
5. cat.addMate(mate);;
6. tx.commit();;
7. session.close();;
8. };
public void addMate(Cat cat, Mate mate); {
Session session = ...;
Transacton tx = ...;
session.update(cat);;
cat.addMate(mate);;
tx.commit();;
session.close();;
};
显然你是需要把Hibernate的操作封装在DAO里面的，让业务层的程序员和Web层的程序员不需要了解Hibernate，直接对DAO进行调用。
此时问题就来了：上面的代码运行正确有一个必要的前提，那就是方法调用参数cat对象必须是一个已经被持久化过的PO，也就是来说，它应该首先从数据库查询出来，然后才能这样用。但是业务层的程序员显然不知道这种内部的玄妙，如果他的业务是现在增加一个cat，然后再增加它的mate，他显然会这样调用，new一个cat对象出来，然后就addMate：
Java代码
1. Cat cat = new Cat();;
2. cat.setXXX();;
3. daoimpl.addMate(cat,mate);;
Cat cat = new Cat();;
cat.setXXX();;
daoimpl.addMate(cat,mate);;
但是请注意看，这个cat对象只是一个VO，它没有被持久化过，它还不是PO，它没有资格调用addMate方法，因此调用addMate方法不会真正往数据库里面发送update的sql，这个cat对象必须先被save到数据库，在真正成为一个PO之后，才具备addMate的资格。
你必须这样来操作：
Java代码
1. Cat cat = new Cat();;
2. cat.setXXX();;
3. daoimpl.addCat(cat);;
4. daoimpl.addMate(cat, mate);;
Cat cat = new Cat();;
cat.setXXX();;
daoimpl.addCat(cat);;
daoimpl.addMate(cat, mate);;
先持久化cat，然后才能对cat进行其他的持久化操作。因此要求业务层的程序员必须清楚cat对象处于何种状态，到底是第一种，还是第三种。如果是第一种，就要先save，再addMate；如果是第三种，就直接addMate。
但是最致命的是，如果整个软件分层很多，业务层的程序员他拿到这个cat对象也可能是上层Web应用层传递过来的cat，他自己也不知道这个cat究竟是VO，没有被持久化过，还是已经被持久化过，那么他根本就没有办法写程序了。
所以这样的DAOImpl显然是有问题的，它会对业务层的程序员造成很多编程上的陷阱，业务层的程序员必须深刻的了解他调用的每个DAO对PO对象进行了何种状态管理，必须深刻的了解他的PO对象在任何时候处于什么确切的状态，才能保证编程的正确性，显然这是做不到的，但是有了 saveOrUpdate，这些问题就迎刃而解了。
现在你需要修改addMate方法：
Java代码
1. public void addMate(Cat cat, Mate mate); {
2. Session session = ...;
3. Transacton tx = ...;
4. session.saveOrUpdate(cat);;
5. cat.addMate(mate);;
6. tx.commit();;
7. session.close();;
8. };
public void addMate(Cat cat, Mate mate); {
Session session = ...;
Transacton tx = ...;
session.saveOrUpdate(cat);;
cat.addMate(mate);;
tx.commit();;
session.close();;
};
如上，如果业务层的程序员传进来的是一个已经持久化过的PO对象，那么Hibernate会更新cat对象(假设业务层的程序员在Session外面修改过cat的属性)，如果传进来的是一个新new出来的对象，那么向数据库save这个PO对象。
BTW: Hibernate此时究竟采取更新cat对象，还是save cat对象，取决于unsave-value的设定。
这样，业务层的程序员就不必再操心PO的状态问题了，对于他们来说，不管cat是new出来的对象，只是一个VO也好；还是从数据库查询出来的的PO对象也好，全部都是直接addMate就OK了：
Java代码
1. daoimple.addMate(cat, mate);;
daoimple.addMate(cat, mate);;
这便是saveOrUpdate的作用。