原文出自 http://blog.csdn.net/woshichenxu/archive/2006/01/22/586361.aspx

1.     关于hibernate缓 存的问题：

1.1.1.         基本的缓存原理

Hibernate缓存分为二级，第一级存放于session中称为一级缓存，默认带有且不能卸载。

第二级是由sessionFactory控制的进程级缓存。是全局共享的缓存，凡是会调用二级缓存的查 询方法都会从中受益。只有经正确的配置后二级缓存才会发挥作用。同时 在进行条件查询时必须使用相应的方法才能从缓存中获取数据。比如Query.iterate()方法、load、get方法等。必须注意的是session.find方法永远是从数据库中获取数据，不会从二级缓存中获取数据，即 便其中有其所需要的数据也是如此。

查询时使用缓存的实现过程为：首先查询一级缓存中是否具有需要 的数据，如果没有，查询二级缓存，如果二级缓存中也没有，此时再执行查询数据库的工作。要注意的是：此3种方式的查询速度是依次降低的。

1.2.   存在的问题

1.2.1.      一级缓存的问题以及使用二级缓存 的原因

     因为Session的生命期往往很短，存在于Session内部的第一级最快缓存的生命期当然也很短，所以第一级缓存的命中率是很低的。其对系统性能的改善也是很有限的。当然，这个Session内部缓存的主要作用是保持Session内部数据状态同步。并非是hibernate为了大幅提高系统性能所提供的。

为了提高使用hibernate的性能，除了常规的一些需要注意的方法比如：

使用延迟加载、迫切外连接、查询过滤等以外，还需要配置hibernate的二级缓存。其对系统整体性能的改善往往具有立竿见影的效果！

（经过自己以前作项目的经验，一般会有3~4倍的性能提高）

1.2.2.      N+1次 查询的问题

执行条件查询时，iterate（）方法具有著名的“n+1”次查询的问题，也就是说在第一 次查询时iterate方法会执行满足条件的查询结果数再加一次（n+1）的查询。但是此问题只存在于第一次查询时，在后面执行相同查 询时性能会得到极大的改善。此方法适合于查询数据量较大的业务数据。

但是注意：当数据量特别大时（比如流水线数据等）需要针对此持 久化对象配置其具体的缓存策略，比如设置其存在于缓存中的最大记录数、缓存存在的时间等参数，以避 免系统将大量的数据同时装载入内存中引起内存资源的迅速耗尽，反而降低系统的性能！！！

1.3.   使用hibernate二级缓存的其他注意 事项：

1.3.1.      关于数据的有效性

另外，hibernate会自行维护二级缓存中的数据，以保证缓存中的数据和数据库中的真实数据的一致性！无论何时，当你调用save()、update()或 saveOrUpdate()方法传递一个对象时，或使用load()、 get()、list()、iterate() 或scroll()方法获得一个对象时, 该对象都将被加入到Session的内部缓存中。 当随后flush()方法被调用时，对象的状态会和数据库取得同步。

也就是说删除、更新、增加数据的时候，同时更新缓存。当然这也 包括二级缓存！

只要是调用hibernate API执行数据库相关的工作。hibernate都会为你自动保证缓存数据的有效性！！

但是，如果你使用了JDBC绕过hibernate直接执行对数据库的操作。此时，Hibernate不会/也不可能自行感知到数据库被进行的变化改动，也就不能再保证缓 存中数据的有效性！！

这也是所有的ORM产品共同具有的问题。幸运的是，Hibernate为我们暴露了Cache的清除方法，这给我们提供了一个手动保证数据有效性的机会！！

一级缓存，二级缓存都有相应的清除方法。

其中二级缓存提供的清除方法为：

按对象class清空缓存

                按对象class和对象的主键id清空缓存

                清空对象的集合中的缓存数据等。

1.3.2.      适合使用的情况

并非所有的情况都适合于使用二级缓存，需要根据具体情况来决 定。同时可以针对某一个持久化对象配置其具体的缓存策略。

适合于使用二级缓存的情况：

1、数据不会被第三方修改；

一般情况下，会被hibernate以外修改的数据最好不要配置二级缓存，以免引起不一致的数据。 但是如果此数据因为性能的原因需要被缓存，同时又有可能被第3方比如SQL修改，也可以为其配置二级缓存。只是此时需要在sql执行修改后手动调用cache的清除方法。以保证数据的一致性

 2、数据大小在可接收范围之内；

     如果数据表数据量特别巨大，此时不适合于二级缓存。原因是缓存的数据量过大可能会引起内存资源紧张，反而降低性能。

如果数据表数据量特别巨大，但是经常使用的往往只是较新的那部 分数据。此时，也可为其配置二级缓存。但是必须单独配置其持久化类的缓存策略，比如最大缓存数、缓存过期时间等，将这些参数降低至一个合理的范围（太高会 引起内存资源紧张，太低了缓存的意义不大）。

 3、数据更新频率低；

     对于数据更新频率过高的数据，频繁同步缓存中数据的代价可能和查询缓存中的数据从中获得的好处相当，坏处益处相抵消。此时缓 存的意义也不大。

 4、非关键数据（不是财务数据等）

  财务数据等是非常重要的数据，绝对不允许出现或使用无效的数据，所以此时为了安全起见最好不要使用二级缓存。

  因为此时“正确性”的重要性远远大于“高性能”的重要性。

2.     目前系统中使用hibernate缓 存的建议

1.4.   目前情况

 一般系统中有三种情况会绕开hibernate执行数据库操作：

   此种情况使用hibernate二级缓存会不可避免的造成数据不一致的问题，

 详细的设计。比如在设计上 避免对同一数据表的同时的写入操作，

   使用数据库各种级别的锁定机制等。

2、动态表相关

   所谓“动态表”是指在系统运行时根据用户的操作系统自动建 立的数据表。

   比如“自定义表单”等属于用户自定义扩展开发性质的功能模块，因为此时数据表是运行时建立的，所以不能进行hibernate的映射。因此对它的操作只能 是绕开hibernate的直接数据库JDBC操作。

      如果此时动态表中的数据没有设计缓存，就不存在数据不一致的问 题。

   如果此时自行设计了缓存机制，则调用自己的缓存同步方法即 可。

3、使用sql对 hibernate持久化对象表进行批量删除时

     此时执行批量删除后，缓存中会存在已被删除的数据。

分 析： 

   当执行了第3条（sql批量删除）后，后续的查询只可能是以下三种方式：

a. session.find（）方法：

根据前面的总结，find方法不会查询二级缓存的数据，而是直接查询数据库。

所以不存在数据有效性的问题。

b. 调用iterate方法执行条件查询时：

根据iterate查询方法的执行方式，其每次都会到数据库中查询满足条件的id值，然后再根据此id 到缓存中获取数据，当缓存中没有此id的数据才会执行数据库查询；

如果此记录已被sql直接删除，则iterate在执行id查询时不会将此id查询出来。所以，即便缓存中有此条记录也不会被客户获得，也就 不存在不一致的情况。（此情况经过测试验证）

c. 用get或load方法按id执行查询：

客观上此时会查询得到已过期的数据。但是又因为系统中执行sql批量删除一般是

针对中间关联数据表，对于

中间关联表的查询一般都是采用条件查询 ,按id来查询某一条关联关系的几率很低,所以此问题也不存在!

   如果某个值对象确实需要按id查询一条关联关系,同时又因为数据量大使用了sql执行批量删除。当满足此两个条件时,为了保证按id 的查询得到正确的结果,可以使用手动清楚二级缓存中此对象的数据的方法!!

(此种情况出现的可能性较小)

1.5.   建议

1、建议不要使用sql直接执行数据持久化对象的数据的更新，但是可以执行批量删除。（系统中需要批量更新的地方也较少）

2、如果必须使用sql执行数据的更新，必须清空此对象的缓存数据。调用

SessionFactory.evict(class)

SessionFactory.evict(class,id)

等方法。

3、在批量删除数据量不大的时候可以直接采用hibernate的批量删除，这样就不存在绕开hibernate执行sql产生的缓存数据一致性的问题。

4、不推荐采用hibernate的批量删除方法来删除大批量的记录数据。

原因是hibernate的批量删除会执行1条查询语句外加满足条件的n条删除语句。而不是一次执行一条条件删除语句！！

当待删除的数据很多时会有很大的性能瓶颈！！！如果批量删除数 据量较大,比如超过50条,可以采用JDBC直接删除。这样作的好处是只执行一条sql删除语句,性能会有很大的改善。同时，缓存数据同步的问题,可以采用 hibernate清 除二级缓存中的相关数据的方法。

调用 SessionFactory.evict(class) ；SessionFactory.evict(class,id)等方法。

所以说，对于一般的应用系统开发而言（不涉及到集群，分布式数 据同步问题等），因为只在中间关联表执行批量删除时调用了sql执行，同时中间关联表一般是执行条件查询不太可能执行按id查询。所以，此时可以直接执行sql删除，甚至不需要调用缓存的清除方法。这样做不会导致以后配置 了二级缓存引起数据有效性的问题。

退一步说，即使以后真的调用了按id查询中间表对象的方法，也可以通过调用清除缓存的方法来解决。

4、具体的配置方法 

根据我了解的很多hibernate的使用者在调用其相应方法时都迷信的相信“hibernate会自行为我们处理性能的问题”，或 者“hibernate会自动为我们的所有操作调用缓存”,实际的情况是hibernate虽然为我们提供了很好的缓存机制和扩展缓存框架的支持，但是必 须经过正确的调用其才有可能发挥作用！！所以造成很多使用hibernate的系统的性能问题，实际上并不是hibernate不行或者不好，而是因为使 用者没有正确的了解其使用方法造成的。相反，如果配置得当hibernate的性能表现会让你有相当“惊喜的”发现。下面我讲解具体的配置方法.

 ibernate提供了二级缓存的接口：
net.sf.hibernate.cache.Provider,
同 时提供了一个默认的 实现net.sf.hibernate.cache.HashtableCacheProvider，
也可以配置 其他的实现 比如ehcache,jbosscache等。

具体的配置位置位于hibernate.cfg.xml文件中
<property name="hibernate.cache.use_query_cache">true</property>
<property name="hibernate.cache.provider_class">net.sf.hibernate.cache.HashtableCacheProvider</property>

很多的hibernate使用者在 配置到 这一步 就以为 完事了，
注意：其实光这样配，根本 就没有使用hibernate的二级缓存。同时因为他们在使用hibernate时大多时候是马上关闭session，所以，一级缓存也没有起到任何作 用。结果就是没有使用任何缓存，所有的hibernate操作都是直接操作的数据库！！性能可以想见。

正确的办法是除了以上的配置外还应该配置每一个vo对象的具体缓存策略，在影射文件中配置。例如：

<hibernate-mapping>
<class name="com.sobey.sbm.model.entitySystem.vo.DataTypeVO" table="dcm_datatype">
<cache usage="read-write"/>
<id name="id" column="TYPEID" type="java.lang.Long">
<generator class="sequence"/>
</id>

<property name="name" column="NAME" type="java.lang.String"/>
<property name="dbType" column="DBTYPE" type="java.lang.String"/>
</class>
</hibernate-mapping>

关键就是这个<cache usage="read-write"/>，其有几个选择
read- only,read-write,transactional,等
然后在执行查询时 注意了 ，如果是条件查询，或者返回所有结果的查询，此时session.find()方法 不会获取缓存中的数据。只有调用query.iterate()方法时才会调缓存的数据。

同时 get 和 load方法 是都会查询缓存中的数据 .

对于不同的缓存框架具体的配置方法会有不同，但是大体是以上的配置

（另外，对于支持事务型，以及支持集群的环境的配置我会争取在后续的文章中中 发表出来）

3.     总结

总之是根据不同的业务情况和项目情况 对hibernate进行有效的配置和正确的使用，扬长避短。不存在适合于任何情况的一个“万能”的方案。

以上结论及建议均建立在自己在对 Hibernate 2.1.2中的测试结果以及以前的项目经验的基础上。如有谬处，请打家提 出指正:)!

最后，祝大家 新年快乐！！在新的一年里 取得人生的进步！！！

打开NetBeans 6.5.1，选择文件—》新建项目，选择Java Web，然后在项目列表中选择 Web 应用程序，下一步

选择使用专用文件夹存储库，指定库文件夹的位置，通常是默认的.\lib，即项目文件夹下的lib文件夹，下一步

选择Web应用服务器。这里选择Tomcat 6.0.18 ，Java EE版本选择 Java EE 5，下一步

在框架对话框中什么都不选择，直接点击完成。

配置项目：

1. 配置OperaMask

在WEB-INF文件夹下新建一个faces-config.xml文件，内容如下：

<?xml version="1.0" encoding="UTF-8"?>

<faces-config xmlns="http://java.sun.com/xml/ns/javaee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd" version="1.2">

<application>

<view-handler>com.sun.facelets.FaceletViewHandler</view-handler>

</application>

</faces-config>

在新创建的项目中，右键单击“库”节点，选择添加库

然后选择导入，选择Spring 2.5库，选择导入库，添加库。

再次选择添加库，然后选择创建。库名称为OperaMask，库类型为类库：

在“定制库”中选择“添加JAR/文件夹”，在弹出的对话框中选择OperaMask的基本jar包，并将导入方式指定为：复制到库文件夹。

一路选是。

2. 配置Spring以及与OperaMask的整合

然后再创建一个OperaMask_SpringCompatibility库，将OperaMask中的spring文件夹下的operamasks-spring.jar添加进来

然后在新创建的项目中展开WEB-INF文件夹，打开web.xml：按照OperaMask包中的blank样例程序的配置进行配置。

之后，在web.xml中配置如下内容：

<context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:applicationContext*.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener>

然后，在源包节点下创建Spring配置文件applicationContext.xml，选择如图所示的几个命名空间：

选择完成，然后在Beans节点之间添加如下内容：

<!-- 开启基于注解的配置 --> <context:annotation-config/> <!-- 使 AOM 中的 LiteBean 同样能够被 Spring 所感应到 --> <bean class="org.operamasks.faces.spring.ManagedBeanConfigurer"/>

3. 配置JPA持久化支持

在服务选项卡中，选择MySQL数据库驱动，然后右键单击，选择连接设置，配置你要使用的数据库：

数据库配置完毕，然后回到项目选项卡，右键单击刚创建的项目，选择新建-->其它-->持久性-->持久性单元

在新建持久性单元对话框中选择持久性库为Hibernate，即选择Hibernate为JPA持久单元的实现，数据库连接选择我们刚配置好的MySQL连接。

单击完成。此时，Hibernate的JPA库已经被添加到项目的lib目录下了。包含了基本的Hibernate jar包和Hibernate JPA支持jar包。

注：使用JPA的一个好处就是我们不需要在一个统一的配置文件里罗列所有的实体类，而是可以让实体管理器自动扫描所有被@Entity注解了的实体类。要实现这种功能，如果项目的JPA实现迁移到TopLink Essential，需要加入下面的配置：

找到项目中的“配置文件”节点，打开persistence.xml文件，调整到XML视图中，在<provider> </provider>节点后添加：

<exclude-unlisted-classes>false</exclude-unlisted-classes> 一行。如果希望使用Hibernate实现，请一定不要加入这一行，否则，您必须将您创建的所有实体类逐一添加到persistence.xml中。

如果要使用Spring提供的JpaTemplate（即实现JpaDaoSupport方式），则回到spring的applicationContext.xml文件，在<beans>节点里面添加：

<!-- 利用Spring的实体管理器工厂来创建JPA实体管理器，传入的参数为persistence.xml中指定的持久化单元名称 --> <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean"> <property name="persistenceUnitName" value="DMCSv1PU"/> </bean> <!-- 声明一个Spring提供的JPA事务管理器，传入的参数正是Spring中的实体管理器工厂 --> <bean id="txManager" class="org.springframework.orm.jpa.JpaTransactionManager"> <property name="entityManagerFactory" ref="entityManagerFactory"/> </bean> <!-- 开启Spring提供的基于注解的声明式事务管理 --> <tx:annotation-driven transaction-manager="txManager"/>

至此，持久化支持配置完毕。

创建实体类和相应的JPA控制类

右键单击项目，选择新建-->其它-->持久性-->通过数据库生成实体类，选择数据库表：

点击下一步，输入合适的包名

下一步，映射选项如下图所示：

选择新建-->其它-->持久性-->基于实体类的JPA控制器类，下一步：

添加要生成控制器类的实体类，下一步：

选择合适的包，然后完成。

后面的配置无非就是将JPA的控制器类写入Spring的配置文件，然后在AOM的LiteBean中注入这些控制器类，实现数据库操作以及相应的业务逻辑。

注：解决Spring与Hibernate JPA的冲突：

如上图所示：选择工具--> 库 --> 库位置-->选择当前编辑的项目，选中Spring Framework 2.5，然后去掉cglib2.2那个jar包。这个包与Hibernate JPA中的cglib 2.1.3.jar有冲突