在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。
　　
　　因此，我们来看看：
　　代码:
　　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了。
　　
　　代码:
　　// 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，如下定义：
　　代码:
　　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：
　　
　　代码:
　　cat cat = new cat();
　　cat.setxxx();
　　daoimpl.addmate(cat,mate);
　　
　　但是请注意看，这个cat对象只是一个vo，它没有被持久化过，它还不是po，它没有资格调用addmate方法，因此调用addmate方法不会真正往数据库里面发送update的sql，这个cat对象必须先被save到数据库，在真正成为一个po之后，才具备addmate的资格。
　　
　　你必须这样来操作：
　　
　　代码:
　　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方法：
　　
　　代码:
　　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了：
　　
　　代码:
　　daoimple.addmate(cat, mate);