一. 序
在实际项目中使用Hibernate有两年多了，在两年多的实践过程中既体验到了Hibernate带来的N多好处，同时也碰到不少的问题，特写此篇文章做个总结，记录自己在Hibernate实践中的一些经验，希望对于新使用Hibernate的朋友能有个帮助，避免走过多的弯路。
阅读本文前建议至少拥有Hibernate的一些基本知识，因为本文不会去详细介绍相关的基本知识，最好就是先用Hibernate开发了一个HelloWorld，^_^。
根据自己所经历的项目中使用Hibernate所涉及的范围，本文从开发环境、开发、设计、性能、测试以及推荐的相关书籍方面进行讲述，本篇文档不会讲的非常细致，只是根据自己在实践时的经验提出一些建议，关于细致以及具体的部分请参阅《Hibernate Reference》或推荐的相关书籍章节。
此文档的PDF版本请到此下载：
http://www.blogjava.net/Files/BlueDavy/Hibernate实践.rar
本文允许转载，但转载时请注明作者以及来源。
作者：BlueDavy
来源：www.blogjava.net/BlueDavy
二. 开发环境
Hibernate开发环境的搭建非常的简单，不过为了提高基于Hibernate开发的效率，通常都需要使用一些辅助工具，如xdoclet、middlegen等。
尽管Hibernate已经封装提供了很简单的进行持久的方法，但在实际项目的使用中基本还是要提供一些通用的代码，以便在进行持久的相关操作的时候能够更加的方便。
2.1. lib
2.1.1. Hibernate lib
Hibernate相关的lib自然是开发环境中首要的问题，这部分可以从Hibernate的官方网站进行下载，在其官方网站中同时提供了对于Hibernate所必须依赖的lib以及其他可选lib的介绍。
2.2. xdoclet
Hibernate作为ORM工具，从名字上就能看出它需要一个从OàR的Mapping的描述，而这个描述就是在使用Hibernate时常见的hbm.xml，在没有工具支持的情况下，需要在编写持久层对象的同时手写这个文件，甚为不便。
在jdk 5.0未推出之前，xdoclet支持的在javadoc中编写注释生成相关配置文件的方式大受欢迎，减少了编写hibernate映射文件的复杂性，手写一个完整的hibernate映射文件出错几率比较的高，再加上手写容易造成编写出来的风格相差很大，因此，基于xdoclet来生成hbm.xml的方式被大量的采用，基于xdoclet来编写能够基于我们在持久层对象上编写的javadoc来生成hbm.xml文件，非常的方便。
2.2.1. Hibernate template
如果没记错的话，大概在04年的时候javaeye上有位同仁整理了一个这样的template文件，^_^，非常感谢，我一直都在用着，呵呵。
这个文件的方便就是把它导入eclipse后，在javadoc中我们可以直接写hibid，然后按eclipse的代码辅助键(alt+/)来生成整个hibernate.id的相关的格式，呵呵，免得在写hibernate.id这些东西的时候过于麻烦，^_^，这个template文件我稍微做了修改，可在这里下载：
http://www.blogjava.net/Files/BlueDavy/templates-eclipse-tags.rar
当然，你也可以选择直接用xdoclet提供的template文件，不过xdoclet官方网站上好像只提供了可直接导入idea的模板文件。
关于注释上的hibernate.id这些东西具体请参见xdoclet官方网站的说明。
如果你的项目采用的是jdk 5，那么就可以直接使用hibernate annotation了，那就更为方便。
2.2.2. Ant task build
Eclipse里没有集成xdoclet的插件，你也可以去安装一个jboss ide的插件，里面有xdoclet的插件，反正我是觉得太麻烦了。
在项目中我仍然采用ant task的方式来生成hbm.xml，target如下所示：
<path id="app.classpath">
<pathelement path="${java.class.path}"/>
<fileset dir="${xdoclib.dir}">
<include name="*.jar"/>
</fileset>
</path>
<target name="hbm" description="生成映射文件">
<tstamp>
<format property="TODAY" pattern="yy-MM-dd"/>
</tstamp>
<taskdef name="hibernatedoclet" classname="xdoclet.modules.hibernate.HibernateDocletTask" classpathref="app.classpath"/>
<hibernatedoclet destdir="src/java" force="true" verbose="true" excludedtags="@version,@author,@todo">
<fileset dir="src/java">
<include name="**/po/**/*.java"/>
</fileset>
<hibernate version ="3.0"/>
</hibernatedoclet>
</target>
这个文件请根据项目情况以及环境稍做修改，^_^，其中需要通过properties文件指明xdocletlib.dir，类似xdocletlib.dir=c:\xdocletlib，里面放置xdoclet的相关jar文件。
在搭建好了这样的环境后，就可以在直接在eclipse中运行ant文件中的这个target来生成hbm.xml。
2.3. Hibernate3 Tools
如果采用Hibernate 3，则可以直接下载Hibernate 3 Tools的Eclipse Plugin，那就可以类似在PL/SQL里执行sql一样在eclipse里执行hql，^_^
2.4. HibernateUtil
为了方便项目中Hibernate的使用，一般来说都会提供HibernateUtil这样的类，这个类的作用主要是创建sessionFactory和管理session，在Hibernate 3以前采用的是在这里建立ThreadLocal来存放session，在Hibernate 3以后则可以直接使用SessionFactory.getCurrentSession来获取session，而session的获取方式则可通过在hibernate.cfg.xml中执行current_session_context_class的属性来决定是采用thread或jta或自定义的方式来产生session。
2.5. CommonDao
在持久层部分目前采用的较多的仍然是dao模式，Hibernate作为ORM工具已经提供了CRUD的封装，类如可以使用session.save()；session.persist()这样简单的方式来完成CRUD的操作，但在实际的项目中还是需要提供一个通用的Dao，来简化对于事务、异常处理以及session的操作，同时提供一些项目中需要的相关操作。
三. 开发
在完成了Hibernate的开发环境的搭建后，就可以基于Hibernate进行持久层的开发了，对于持久层开发来说，会涉及到实体的编写、实体的维护以及实体的查询三个部分。
3.1. 实体的编写
Hibernate的一个明显的优点就是在于可透明化的对对象进行持久，这也就意味着持久对象根本就不需要依赖任何的东西，可以采用POJO的方式来编写，在Hibernate 3以上版本还提供了对于Map、XML的方式的持久的支持，就更方便了，在项目中，更多采用的仍然是POJO的方式。
在实体的编写上应该说不会有什么问题，只要仔细查看xdoclet关于hibernatedoclet部分的说明即可完成。
这块需要学习的主要是普通的值类型注释的编写、id字段注释的编写、关联注释的编写，这些部分xdoclet均提供了较详细的说明。
3.2. 实体的维护
3.2.1. 新增/编辑/删除
新增/编辑/删除是持久操作中最常使用的维护性操作，基于Hibernate做这样的维护就比采用sql的方式简单多了，通过上面CommonDao，就可以直接完成dao.save、dao.update、dao.delete的操作，而且在Hibernate 3也支持了批量的insert、update和delete。
这个部分中需要注意的是Hibernate对于对象的三种状态的定义：
u Transient
很容易理解，就是从未与session发生过关系的对象，^_^，例如在代码中直接User user=new User()；这样形成的user对象，就称为Transient对象了。
u Detached
同样很容易理解，就是与session发生过关系的对象，但session已经关闭了的情况下存在的对象，例如：
User user=new User();
user.setName(“bluedavy”);
session.save(user);
session.close();
在session.close()后这个时候的user对象就处于Detached状态之中了，如果想将这个对象变为Persistent状态，可以通过session.merge或session.saveOrUpdate()等方式来实现。
Detached状态的对象在实际的应用中最常采用，从概念上我们可以这么理解，处于Detached状态的对象可以看做是一个DTO，而不是PO，这从很大程度上就方便了PO在实际项目中的使用了。
u Persistent
Persistent状态就是指和Session发生了关系的对象，并且此时session未关闭，举例如下：
User user=new User();
user.setName(“bluedavy”);
session.save(user);
user.getName();
在session.save后user就处于Persistent状态，此时如果通过session根据user的id去获取user对象，则可发现获取的对象和之前的user是同一个对象，这是session一级缓存所起的作用了，当然，也可以强制的刷新session的一级缓存，让session从数据库中重新获取，只需要在获取前执行session.evict(user)或session.clear()。
3.2.2. 关联维护
关联维护在Hibernate中表现出来可能会让熟悉使用sql的人有些的不熟，但其实以对象的观点去看是会觉得很正常的。
在Hibernate的关联维护中，最重要的是inverse和cascade两个概念。
u inverse
inverse从词义上看过去可能不是那么容易理解，其实它的意思就是由谁来控制关联关系的自动维护，当inverse=true就意味着当前对象是不能自动维护关联关系，当inverse=false就意味着当前对象可自动维护关联关系，还是举例来说：
假设Org和User一对多关联，
当org中getUsers的inverse=false的情况：
org.getUsers().add(user);
dao.save(org);
这样执行后将会看到数据库中user这条记录中的orgId已经被设置上去了。
当inverse=true的情况下，执行上面的代码，会发现在数据库中user这条记录中的orgId没有被设置上去。
^_^，inverse的作用这样可能看的不是很明显，在下面的一对多中会加以描述。
u cascade
cascade的概念和数据库的cascade概念是基本一致的，cascade的意思形象的来说就是当当前对象执行某操作的情况下，其关联的对象也执行cascade设置的同样的操作。
例如当org.getUsers的cascade设置为delete时，当删除org时，相应的users也同样被删除了，但这个时候要注意，org.getUsers这个集合是被删除的user的集合，也就是说如果这个时候数据库中新增加了一个user给org，那么这个user是不会被删除的。
cascade的属性值详细见《Hibernate reference》。
3.2.2.1. 一对一
一对一的关联维护在实际项目中使用不多，一对一在Hibernate中可采用两种方式来构成，一种是主键关联，一种是外键关联。
一对一的使用推荐使用主键关联，具体配置方法请参见《Hibernate Reference》。
3.2.2.2. 一对多/多对一
一对多/多对一的关联维护在实际项目中使用是比较多的，在Hibernate中可采用多种方式来配置一对多的关联，如采用Set、List、Bag、Map等，具体在《Hibernate Reference》中都有详细说明。
在这里我想说的一点就是关于inverse的设置，在一对多的情况下建议将一端的inverse设为true，而由多端去自动维护关联关系，为什么这样做其实挺容易理解的，假设org和user为一对多的关联，org.getUsers的inverse设置为false，org.getUsers().add(user);dao.update(org);当update的时候org所关联的所有user的orgId都会更新一次，可想而知这个效率，而如果改为在多端维护(多端设置为inverse=false)，则是这样：user.setOrg(org);dao.update(user);当update的时候就仅仅是更新user这一条记录而已。
另外一点就是合理的设置cascade，这个要根据需求来实际决定。
3.2.2.3. 多对多
多对多的关联维护在实际项目中其实也是比较多的，尽管在《Hibernate Reference》中认为多对多的情况其实很多时候都是设计造成的。
多对多的关联也同样可以采用Set、List等多种方式来配置，具体在《Hibernate Reference》中也有详细的说明。
多对多的关联维护上没有什么需要多说的，在实践过程中来看这块不会出什么太多问题，唯一需要注意的是合理设置cascade，这个要根据项目的实际情况而定。
3.3. 实体的查询
Hibernate提供了多种方式来支持实体的查询，如对于原有熟悉sql的人可以继续使用sql，符合对象语言的对象查询语句(HQL)以及条件查询API(Criteria)。
在熟练使用hql或criteria的情况下，我相信你会觉得Hibernate的查询方式会比采用sql的方式更加简便。
3.3.1. 符合对象语言的查询语句
Hibernate提供了一种符合对象语言的查询语句，称为HQL，这种语句的好处是能够避免使用sql的情况下依赖数据库特征的情况出现，同时它带来的最大的好处就是我们能够根据OO的习惯去进行实体的查询。
对于HQL没有什么多讲的，如果熟悉sql的人应该也是能够很快就学会HQL，而如果不熟悉sql的人那也没关系，HQL的上手是非常容易的，具体请参考《Hibernate Reference》。
3.3.2. 占位符式的查询
占位符式的查询(就是采用?替换查询语句中的变量)是在采用sql的情况下经常使用的一种查询方式，也是查询时推荐使用的一种方式。
Hibernate中的查询参数主要有两种类型：值类型和实体类型，值类型就是指一个切实的值(如String、int、List这些)，实体类型就是一个具体的实体，如编写的User、Organization等，值类型的查询和普通sql几乎一样，而实体类型的查询就体现了Hibernate的强项，^_^，可以起到简化sql的作用，并且使得查询语句更加容易理解。
3.3.2.1. 值类型
3.3.2.1.1. 简单值
举例如下：
from User u where u.name=:username and u.yearold=:yearold
这就是一个常见的简单值的占位符式的查询，通过这样的方式就可以把值注入到参数中：
query.setParameter(“username”,”bluedavy”);
query.setParameter(“yearold”,25);
同样，hibernate也支持和sql完全相同的?的方式，那么上面的语句以及注入参数的方式就变为了：
from User u where u.name=? and u.yearold=?
query.setParameter(0,”bluedavy”);
query.setParameter(1,25);
推荐使用第一种，那样参数的意义更容易被理解。
3.3.2.1.2. in查询
in查询也是经常被使用到的一种查询，在Hibernate中表现出来会稍有不同，不过如果按照对象观点去看就很容易理解了，例如下面这句：
from User u where u.name in (:usernameList)
在Hibernate中通过这样的方式将值注入到这个参数中：
List list=new ArrayList();
list.add(“jerry”);
list.add(“bluedavy”);
query.setParameterList(“usernameList”,list);
在sql中通常是组装一个由,连接的值来构成in中的参数值，而在Hibernate中则依照对象转化为采用list了，^_^，是不是更方便些。
3.3.2.2. 实体类型
在Hibernate中关联采用的都是对象形式，表现对外就是隐藏了数据库的外键的部分，这也就对习惯使用sql查询的人带来一个问题，因为无法再操作外键字段，那么在涉及到关联的实体的查询时应该怎么做呢，我把它分为单实体和实体集合两种情况来说说。
3.3.2.2.1. 单实体
单实体的查询对应到sql情况通常是在一对多的情况下通过多端查询同时结合一端的一些过滤条件，在sql中通常采用join的方式来实现这个，而在Hibernate中要实现这点就更容易了，举例如下：
User和Organization是一对多，现在要查询属于组织机构名称为”Blogjava”以及用户年龄大于20的用户：
from User u where u.org.name=:orgname and u.yearold>:yearold
query.setParameter(“orgname”,”Blogjava”);
query.setParameter(“yearold”,20);
可以看到这样的查询语句比sql更简单多了，同时也更容易理解多了。
3.3.2.2.2. 实体集合
实体集合过滤形式的查询在实际的项目中也经常会碰到，仍然用上面的例子，但改为通过Organization去查询：
from Organization org where org.name=:orgname and org.users.yearold>:yearold
是不是比sql简单多了，而且更容易理解呢，^_^
这个时候对象化查询语句的优势就体现出来了，而不用陷入sql的那种关系型的通过外键进行查询的方式。
3.3.3. NamedQuery
NamedQuery的意思就是指在PO的映射文件中定义关于PO的查询语句，而在应用中指需要直接调用此查询语句的别名即可，这个好处非常明显，使得所有的查询语句可以统一的进行管理，同样，我们可以在PO中通过javadoc的方式进行定义，这就更方便了，^_^
操作NamedQuery的方法和普通hql的方法基本一样：
session.getNamedQuery(queryname);
其中的queryname就是我们定义的查询语句的别名，一个namedQuery的语句的示例如下：
<query name="validate"><![CDATA[
from User u where u.loginname=:loginname and u.password=:password
]]></query>
3.3.4. Criteria
条件查询的API使得我们可以采用完全对象化的方式进行实体的查询，而不是通过hql的方式，在实际项目中，使用hql的方式更为居多，毕竟写起来更方便。
关于Criteria的具体介绍请参阅《Hibernate Reference》。
3.3.5. 原生SQL
原生SQL不推荐使用，但在某些确实需要用sql的情况下那么Hibernate还是支持的，具体见《Hibernate Reference》。
四. 设计
独立的编写这个章节的原因是希望在采用Hibernate的情况下充分的去发挥Hibernate的优势，改变我们以关系形式去做持久层的设计的惯性思维，形成以OO的思想去设计持久层，所以我非常推荐通过写PO去生成数据表的方式，而不是设计表反向导成PO的形式，当然，对于原有的系统那就没办法了。
OO思想中的核心三要素：封装、继承和多态，在Hibernate的支持下同样可以充分发挥OO的三要素来优化持久层的设计。
4.1. 封装
4.1.1. Component
Hibernate中有一个Component的概念，这就允许在进行持久层设计的时候采用细粒度级的领域模型进行设计，例如在User对象中需要记录User的firstname、lastname这些信息，而在其他的表中也有这种需求，那么在Hibernate中我们就可以把firstname、lastname组装为一个UserName对象，作为Component放入User中，在user中就可以变为采用user.getUserName.getFristName的方式来获取。
Component对于我们采用对象的封装概念进行持久层设计提供了很好的支持，同时在Hibernate中还有Elements、Properties这些元素，具体请参见《Hibernate Reference》。
4.2. 继承
继承使得我们可以对持久层中的对象进行抽象，类如我们可以形成Person这个对象，而User、Employee都继承自这个对象。
继承在数据库形式的设计中固然也可以实现，但通常不能以对象的观点去发挥的淋漓尽致，当然不是说以对象的方式去设计一定是最好的。
在Hibernate中对于继承映射到数据表有几种不同的策略，各有适用的不同场合，具体的解释和说明见《Hibernate Reference》
4.2.1. 单表策略
单表策略很容易理解，就是将类、子类中所有的属性都放至一张表中，这对于子类属性不多的情况非常有效。
在Hibernate中通常将子类定义为@hibernate.subclass的方式来实现这个策略。
4.2.2. 每个子类一张表
每个子类一张表在Hibernate中有几种实现方式，@hibernate.join-subclass、@hibernate.join-subclass-key的组合方式以及@hibernate.join-subclass、@hibernate.discriminator的组合方式是较常用的两种方式，第一种方式采用的是主键关联方式，第二种方式采用的是discriminator字段的关联方式，个人比较推崇第一种方式。
这种策略适合在子类属性和父类有较大不同的情况下采用。
4.2.3. 每个具体类一张表
这种策略适合在类层次结构上有一定数量的抽象类的情况下使用，同样有两种方式，一种是采用显式多态的方式，另一种是采用隐式多态的方式，显式多态采用的为@hibernate.union-subclass的方式，隐式多态则采用每个具体类的PO独立建表的策略，在它的映射文件中将看不出任何的和接口、抽象类的关系，同时对于抽象类，需要指明其abstract=”true”。
4.3. 多态
4.3.1. 查询
在查询中很容易体现Hibernate对于多态的支持，如系统有Person对象、User和Employee分别继承自Person，同时Person和Organization对象关联，这个时候我们通过Organization获取其关联的Person时得到的既有可能是User，也有可能是Employee，^_^…
五. 性能
Hibernate作为ORM工具，从性能上来讲带给了很多人忧虑，但我觉得Hibernate在性能上也许会带来少许的降低，但如果对于不能合理设计数据库和使用SQL的人来说，我觉得Hibernate反倒能提高性能，除非是在一些特殊的场合，如报表式的那种查询推荐继续采用JDBC的方式。
Hibernate在性能提升上其实有很多种做法，在《Hibernate Reference》中也有专门的提升性能的章节，在这里我提几点在项目中通常采用的方法。
5.1. Lazy Load
Lazy Load是常用的一种提升性能的方法，这个其实很容易理解，在不采用lazy load的情况下，Hibernate在获取一个PO的时候，将同时获取PO中的属性、PO中的集合以及集合中对象的属性、集合，这样看过去很容易看出，如果对象的关联结构有深层次的话，最后搞不好整个库都被加载出来了，而在实际使用中往往可能只需要用到PO中的一两个属性而已，这点也是之前的ORM产品经常被批的一点，就是ORM产品不能象sql那样只获取需要的东西，^_^，其实Hibernate在这点上一直就支持，而且支持的还不错，在Hibernate 3以后，默认的lazy就已经设置为true了，这个时候包括po中的属性都是采用lazy load的方式，只有在调用到这个属性时才会从缓存或数据库中加载，当然，集合也同样如此。
在lazy load上推荐不要什么字段都采用lazy load的方式，对于一些基本属性的字段建议将其lazy设置为false，而对于一些可能需要消耗内存的字段，如clob这样的字段对象的lazy设置为true，对于集合则全部设置为lazy=true。
是否采用Lazy load对系统的性能会有非常明显的影响，同时尽量不要将Detached Object放入Http的session中。
5.1.1. OSIV
OSIV：Open Session In View，在B/S系统中通常采用这种方式来更好的去支持Lazy load，意思就是在View加载前打开Session，在View加载完毕后关闭Session的方式，在Spring中有OpenSessionInViewFilter，可参考或直接使用。
5.2. Cache
Cache是在提升系统性能方面常用的方法，在Hibernate中通常有非常好的对于Cache的支持方法，Hibernate中对于Cache有一级缓存和二级缓存的概念，一级缓存是必须的，位于Session部分，二级缓存则不是必须的，由开发人员自行指定，二级缓存可指定使用何种开源的cache工具，Hibernate 3以后的版本默认使用的是Ehcache，也可以切换为Oscache、JbossCache，对我而言最重要的区别在于对于cluster的支持上。
二级缓存能够明显的提高系统的性能，当然，同时也会更加的消耗内存，可以通过配置文件来指定内存中能够加载的最多的元素，这有利于避免消耗过多内存。
二级缓存的设置在Hibernate中非常的简单，只需要在相应的hbm.xml中增加cache元素，指明使用何种策略，如read-only、read-write等，也可以直接在hibernate.cfg.xml中增加class-cache的方式来进行全局指定。
5.3. 高效的查询语句
查询语句的是否高效对于系统的性能也是会造成明显的影响的，为了方便系统性能的调优，建议大家对查询语句进行统一管理，如统一采用NamedQuery的方式，在这样的情况下可以在系统运行时请教数据库专家，由他们来分析系统中的查询语句的执行效率以及提出改进策略，而对于开发人员来讲，在查询语句方面最能够注意的就是采用占位符式的查询。
5.3.1. 占位符式的查询
数据库对于所有的sql语句都要进行语法分析，而其分析通常会受到语句中的大小写、空格以及参数不同的影响，在其语法分析器认为不同的情况下将再次进行分析，这就不可避免的降低了响应的速度，而采用占位符式的查询则可保证语法分析器只进行一次的分析，在参数不同的情况并不会出现重复解析的现象，其次就是要统一查询语句的编写风格，包括大小写、空格这些。
我不是很确定Hibernate中对于语句的语法分析，估计和数据库的这种方式应该差不多，不过猜想可能会更智能一些，^_^
5.4. 一些配置
在hibernate.cfg.xml中的一些配置也会对性能产生一定的影响，如jdbc.fetch_size的设置等，还有象采用连接池方面的设置，对于B/S应用的情况建议尽量采用应用服务器提供的JNDI的方式。
5.5. 建议
在性能提升方面从两方面入手，一是持久层对象的设计上，这方面可以参考《Hibernate Reference》中提升性能章节中的一些建议，另一方面则是请教数据库专家，由数据库专家对表结构、查询语句等进行分析来给出改进策略，在现有的一个项目中，竟然有出现Hibernate在外键上没建立索引的现象出现？
六. 测试
6.1. 编写专门的测试用的配置文件
测试方面也是极度关心的话题，在测试方面其实比较简单，只需要在测试类中采用专门用于测试的配置文件即可，在这个配置文件中，通过都是采用设置hbm2ddl.auto属性为create-drop的方式，也就是在测试类运行前创建表，在测试类运行后删除表的策略，在更多的情况下，我们可以采用in-memory的数据库的方式，如hsql，当然，有些时候则需要和实际运行环境一致，那么就需要采用建立专门的测试库的方式，避免测试数据和运行数据的相互影响。
七. 企业应用开发
事务和并发是企业应用开发中非常关注的两个话题，在《Hibernate Reference》中提供了详细的方案，在这里我就简单的说说。
7.1. 事务
事务是企业应用开发中非常重视的一点，而在Hibernate中操作此部分和sql方式没有什么很大的区别，可以通过session主动去获取Transaction来实现事务控制，同时也可以交由应用服务器提供的JTA来实现事务控制。
在事务这个级别上如果有更高的要求，建议采用Spring的事务框架。
7.2. 并发
在并发方面多采用锁策略，锁策略和数据库基本相同，同样是乐观锁和悲观锁两种策略，乐观锁策略在Hibernate中推荐使用version或timestamp来实现，具体覆盖方式则需要根据应用而定，如是采用最新的修改的覆盖还是采用版本冲突策略等，悲观锁策略则通过指定对象的锁方式，如LockMode.READ，引用《Hibernate Reference》中的一段话：
“用户其实并不需要花很多精力去担心锁定策略的问题。通常情况下，只要为JDBC连接指定一下隔离级别，然后让数据库去搞定一切就够了。然而，高级用户有时候希望进行一个排它的悲观锁定，或者在一个新的事务启动的时候，重新进行锁定。Hibernate总是使用数据库的锁定机制，从不在内存中锁定对象！
如果数据库不支持用户设置的锁定模式，Hibernate将使用适当的替代模式，这一点可以确保应用程序的可移植性。”。
用户可通过几种方式来指定锁定模式：
u Session.load()的时候指定锁定模式LockMode；
u Session.lock()；
u Query.setLockMode()。
八. 相关书籍
Hibernate上手并不难，但要真正的用好它确实不是件容易的事，有些书籍能够很好的帮我们快速的提供解决思路和解决方案，而这些书籍我们也应该常备，以方便自己在有些问题上的解答。
同时，我一直坚持的观点，一种开源框架通常带来的不仅仅是开发、使用上的改变，带来的最大的改变仍然是在设计层次上的，设计上能否充分的发挥开源框架的优势才是最为重要的。
8.1. 《Hibernate Reference》
这本没什么说的，必读书籍，也许在读的时候很多东西你不会觉得什么，但当碰到一些确定方向的问题时，可以通过此书快速的查找到相应的解决方案，感谢Redsaga组织的翻译工作，使得我们可以有中文版可看。
目前版本(Hibernate 3.1.2)的下载地址：
http://www.redsaga.com/hibernate-ref/3.1.2/zh-cn/pdf/hibernate_reference.pdf
8.2. 《Hibernate in action》
In action系列的书籍也没啥多说的，强烈推荐看看，尽管现在看起来版本有些老了，但里面很多的实践思想仍然是非常值得学习的，网上应该有很多电子版下载的地方。
8.3. 《深入浅出Hibernate》
这本书想必大家也听闻了不少，简称白皮书，^_^，是夏昕、曹晓刚以及唐勇三位大师的大作。