spring+hibernate的clob大字段处理（转载于javaeye论坛）

在spring中如何处理oracle大字段

在spring中采用OracleLobHandler来处理oracle大字段（包括clob和blob），则在程序中不需要引用oracle的特殊类，从而能够保证支持我们的代码支持多数据库。

1、首先数据表中的clob类型对应java持久化类的String类型；而blob类型对应byte[]类型
2、定义hibernate标签时，持久化类中对应clob类型的属性的hibernate type应为org.springframework.orm.hibernate.support.ClobStringType；而对应blob类型的属性的hibernate type应为org.springframework.orm.hibernate.support.BlobByteArrayType。
3、以后访问这些对应clob和blob类型的属性时，按普通属性处理，不需要特别编码。

java代码:  

 < bean  id ="mySessionFactory2"  class ="org.springframework.orm.hibernate.LocalSessionFactoryBean" >  
         < property  name ="dataSource" >  
                 < ref  bean ="myDataSource2" />  
          </ property >  
          < property  name ="lobHandler" >  
         < ref  bean ="oracleLobHandle" />  
          </ property >   
 </ bean >  
 < bean  id ="nativeJdbcExtractor"  class ="org.springframework.jdbc.support.nativejdbc.SimpleNativeJdbcExtractor" />  

 < bean  id ="oracleLobHandle"  class ="org.springframework.jdbc.support.lob.OracleLobHandler"  Lazy-init ="true" >  
 < property  name ="nativeJdbcExtractor" >  
     < ref  local ="nativejdbcExtractor" />  
 </ property >  
 </ bean > 

 JavaBean的对应的属性类型为String。

需要注意两点：(1)如果使用Oracle9i自带的class12.jar这个JDBC驱动的话是不行的，会报错，据说要升级到classes12-9i.jar，我在Oracle的网站上没找到对应的下载，下载了ojdbc14.jar就可以了。(2)对Clob或Blog的操作必须在一个事务中进行，如在Dao层测试会出错，在配置了事务的Logic层就没问题了。

经过测试,如果用Oracle10g的JDBC驱动就没这么麻烦了，Hibernate+Oracle+CLOB的读写其实只要这样做：

1.在Oracle里设置某字段为clob类型。
2.在Hibernate的配置文件里使用网上下载的Oracle 10g最新的jdbc驱动。
3.实体类里把clob字段对应的属性类型设置为String。
4.hibernate的映射文件*.hbm.xml里把该字段对应的类型该为text。

然后就可以在程序里把它当成String随便用了。

补充：按照上面的方法又写了一个测试类，能够操作Clob字段了，但是启动JBOSS后就不能用了，后来找了很久才发现，原来我用的JBOSS的default/lib目录下也有一下老版本的Class12.jar，删除它换成最新的ojdbc14.jar就可以了。

1 String hqlStr  =   " from TUser as user where user.name=’Erica’ " ; 
2 Query query  =  session.createQuery(hqlStr); 
3 query.setLockMode( " user " ,LockMode.UPGRADE);  // 加锁 
4 List userList  =  query.list(); // 执行查询，

获取数据 query.setLockMode 对查询语句中特定别名所对应的记录进行加锁（我们为 TUser类指定了一个别名“user”），这里也就是对返回的所有user记录进行加锁。 观察运行期Hibernate生成的SQL语句： 

1 select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex from t_user tuser0_ where (tuser0_.name = ’Erica’ )  for  update

 这里Hibernate通过使用数据库的for update子句实现了悲观锁机制。

上面这两种锁机制是我们在应用层较为常用的，加锁一般通过以下方法实现：
Criteria.setLockMode
Query.setLockMode
Session.lock
注意，只有在查询开始之前（也就是Hiberate 生成SQL 之前）设定加锁，才会 真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含for update 子句的Select SQL加载进来，所谓数据库加锁也就无从谈起。

< hibernate - mapping >  
< class  
name = " org.hibernate.sample.TUser "  
table = " t_user "  
dynamic - update = " true "  
dynamic - insert = " true "  
optimistic - lock = " version "  
>  
…… 
</ class >  
</ hibernate - mapping >  

 1 < hibernate - mapping >   
 2 < class   
 3 name = " org.hibernate.sample.TUser "   
 4 table = " t_user "   
 5 dynamic - update = " true "   
 6 dynamic - insert = " true "   
 7 optimistic - lock = " version "   
 8 >   
 9 < id  
10 name = " id "   
11 column = " id "   
12 type = " java.lang.Integer "   
13 >   
14 < generator  class = " native " >   
15 </ generator >   
16 </ id >   
17 < version  
18 column = " version "   
19 name = " version "   
20 type = " java.lang.Integer "   
21 />   
22 ……  
23 </ class >   
24 </ hibernate - mapping >   
25

注意version 节点必须出现在ID 节点之后。
 这里我们声明了一个version属性，用于存放用户的版本信息，保存在TUser表的 version字段中。 此时如果我们尝试编写一段代码，更新TUser表中记录数据，如：
代码内容

1 Criteria criteria  =  session.createCriteria(TUser. class );  
2 criteria.add(Expression.eq( " name " , " Erica " ));  
3 List userList  =  criteria.list();  
4 TUser user  = (TUser)userList.get( 0 );  
5 Transaction tx  =  session.beginTransaction();  
6 user.setUserType( 1 );  // 更新UserType字段  
7 tx.commit();  
8

每次对TUser进行更新的时候，我们可以发现，数据库中的version都在递增。 而如果我们尝试在tx.commit 之前，启动另外一个Session，对名为Erica 的用 户进行操作，以模拟并发更新时的情形：
代码内容

 1 Session session =  getSession();  
 2 Criteria criteria  =  session.createCriteria(TUser. class );  
 3 criteria.add(Expression.eq( " name " , " Erica " ));  
 4 Session session2  =  getSession();  
 5 Criteria criteria2  =  session2.createCriteria(TUser. class );  
 6 criteria2.add(Expression.eq( " name " , " Erica " ));  
 7 List userList  =  criteria.list();  
 8 List userList2  =  criteria2.list();TUser user  = (TUser)userList.get( 0 );  
 9 TUser user2  = (TUser)userList2.get( 0 );  
10 Transaction tx  =  session.beginTransaction();  
11 Transaction tx2  =  session2.beginTransaction();  
12 user2.setUserType( 99 );  
13 tx2.commit();  
14 user.setUserType( 1 );  
15 tx.commit();  
16

执行以上代码，代码将在tx.commit()处抛出StaleObjectStateException异 常，并指出版本检查失败，当前事务正在试图提交一个过期数据。通过捕捉这个异常，我 们就可以在乐观锁校验失败时进行相应处理。 

<hibernate-mapping>
  <class name="Product" 
        discriminator-value="0"  lazy="false">
    <id name="id" type="long"/>       
    <discriminator 
        formula="(select pr.SubProductAllowable 
                from ProductRelease pr 
                where pr.productReleaseID=
                        productReleaseID)"
        type="integer" />
    <subclass  name="NestedProduct"  
        discriminator-value="1"/>
  </class>
</hibernate-mapping>

    如果 formula 表达式评估结果为 0 时－－也就是不允许次品出厂－－那么对象将是 Product 类。如果结果是 1，那么对象将是 NestedProduct。在表 1 和 2 中，表 Product 的第一条记录（ProductID=10000001），已初始化的类将是 NestedProduct，因为它参考一条 SubProductAllowable=1 的 ProductRelease 记录。表 Product 的第二条记录（ProductID=20000001），已初始化的类将是 Product，因为它参考一条 SubProductAllowable=0 的 ProductRelease 记录。
   

S/N	ProductReleaseID	SubProductAllowable	...
1	11	1	¡­
2	601	0	¡­

        表 1. ProductRelease 表中的记录
   

S/N	ProductID	ProductReleaseID	...
1	10000001	11	¡­
2	20000001	601	...

        表 2. Product 表中的记录
   
    Property
   
    在 property 元素中的 formula 允许对象属性包含特定引伸值，比如对结果进行 sum、average、max 等等。

<property name="averagePrice" formula="(select avg(pc.price) from PriceCatalogue pc, SelectedItems si where si.priceRefID=pc.priceID)"/>

    此外，formula 也能协助从基于当前记录的特定值向其它表检索数据。例如：

<property name="currencyName" formula="(select cur.name from currency cur where cur.id= currencyID)"/>

    这将由助于从 currency 表检索 currency name。正如你所看到的，这样直接映射可消除许多转换编码。
   
    map-key
   
    formula 允许 map-key 持有任何可能的值。下列范例（图 3），我们想让 Role_roleID 成为对象模型的 map-key（图 4）。

                    
                          图 3. 用户角色数据 schema

  
                            图 4. 用户角色对象模型
   
    在前面的数据 schema 中，User 和 Role 由 User_has_Role 通过 many-to-many 关系关联调用。为了获取某个 User 所有的指派角色，我们进行如下映射：

<hibernate-mapping>
  <class name="User">
    <id name="userID"/>
    <map name="roles"  
        table="UserRole"/>
      <key column="User_userID"/>
      <map-key 
        formula="Role_RoleID" 
        type="string"/>
      <many-to-many 
        column="Role_RoleID"
        class="Role"/>
    </map>
  </class>
  <class name="Role">
    <id name="roleID"/>
  </class>
</hibernate-mapping>

    Role_RoleID 通常用于连接 many-to-many 元素的栏位值。Hibernate 通常不允许 Role_RoleID 出现在 map-key 和 many-to-many 的栏位属性中。但是有了 formula，Role_RoleID 也能用于 map-key。
   
    element、map-key-many-to-many 以及其他
   
    element 和 property 类似，能从任何有效的 formula 表达式赋予评估值。
   
    map-key-many-to-many 中 formula 的用法类似于 map-key。但是，map-key-many-to-many 通常用于三重关系，map key 是一个被自己参考的对象，而不是被参考的属性。
   
    那么，到底哪些情况下 formula 不支持呢？有些数据库（例如 Oracle 7）就不支持嵌入式 select 语句（也就是说一条 select SQL 内嵌在另外一条 select SQL 语句中），这种情况 formula 就不支持评估结果。因此，你应该首先检查嵌入式 select SQL 语句是否被支持。
   
    一旦 Hibernate 的映射拿 formula 表达式作为 select SQL 选取的一部分，请确认数据库 SQL 方言是否允许使用 formula，尽管这样将降低代码轻便性。
   
范畴 2：formula 用于连接

    many-to-one
   
    另一个普遍的场景是真实世界的数据模型是所有者关系映射，这意味着映射是不同于 one-to-one、one-to-many 以及 many-to-many 关系的，formula 是提供所有者关系管理元素中的一个。图 5 展示了某公司可有多个联系人，但是其中只有一个为默认联系人的范例。一个公司有多个联系人是典型的 one-to-many 关系。但是，为了标识默认联系人，ContactPerson 表使用了 defaultFlag 参数（1 是 yes, 0是 no）。

               
                        图 5. 用户角色数据 schema

             
                           图 6. 用户角色对象模型
   
    为了说明对象模型（图 6）中默认联系人关系，我们使用如下映射文件：

<hibernate-mapping>
  <class name="Company" table="Company">
    <id name="id" />
    <many-to-one 
      name="defaultContactPerson" 
      property-ref="defaultContactPerson">
        <column name="id"/>
        <formula>1</formula>
        </many-to-one>
  </class>
  <class name="Person" >
    <id name="id" />
    <properties name="defaultContactPerson">
        <property name="companyID" />
        <property name="defaultFlag" />
    </properties>
  </class>
</hibernate-mapping>

    如上，我们把 companyID 和 defaultFlag 组织到名为 defaultContactPerson 的 properties 元素中，做为 Person 表的 unique key。Company 类中的 many-to-one 元素连接 Person 表的 defaultContactPerson properties 元素。输出的 SQL 像这样：
   
    select c.id, p.id from Company c, Person p where p.companyID=c.id and p.defaultFlag=1
   
    one-to-one
   
    Hibernate 中，one-to-one 主要用于两张表共享同一主键的情况。对于外键关联，我们通常使用 many-to-one 来代替。但是，有了 formula，one-to-one 可以通过外键连接表。上面的 many-to-one 范例可以通过 one-to-one 来映射：

<hibernate-mapping>
  <class name="Company" table="Company" >
    <id name="id" />
    <one-to-one name="defaultContactPerson" 
        property-ref="defaultContactPerson" >
    <formula>id</formula>
    <formula>1</formula>
    </one-to-one>
  </class>
  <class name="Person" >
    <id name="id" />
    <properties name="defaultContactPerson">
      <property name="companyID" />
      <property name="defaultFlag" />
    </properties>
   </class>
</hibernate-mapping>

    many-to-many
   
    formula 用于当 many-to-many 元素为关系表和实体表连接的特殊关系，尽管通常没有必要这样用。
   
总结

    文章范例展示了大部分 formula 的适用情景。当需要 formula 评估值时，formula 表达式将出现在 产生的 SQL 语句的 select 部分。当 formula 用于连接时，它出现在产生的 SQL 语句的 where 部分。此外，formula 表达式可用于任何 SQL 方言，只要目标数据库支持。最后，formula 可协助完成从数据模型到对象模型的无代码细粒度映射。


请注意！引用、转贴本文应注明原译者：Rosen Jiang 以及出处：http://www.blogjava.net/rosen

作者：邱洋
QQ：1964477

    虽然在hibernate中有show_sql选项，但是显示出来的语句大多类似
    select * from xxx where value=?
    但是有时候我们需要得到完整的SQL语句，怎么办呢？使用P6SPY就可以完成这个任务

    p6spy是一个开源软件，它可以跟踪任何使用jdbc的应用产生的数据库操作。特别适合于监控ejb服务器产生的 sql statements。
    官方网址：http://www.p6spy.com/
    目前p6spy 适用的应用服务器包括jboss, atg, orion, jonas, iplanet, weblogic, websphere, resin and tomcat.

下面我介绍一下p6spy在tomcat应用程序上安装的步骤：
（1）http://www.p6spy.com/download.html，下载zip包
（2）解压出p6spy.jar spy.properties两个文件
（3）将p6spy.jar 放入应用程序的WEB-INF/lib目录，将spy.properties放入WEB-INF/classes目录
（4）修改spy.properties

    realdriver  =com.mysql.jdbc.Driver  将这行前面的#去掉
    logfile     = c:/spy.log  修改一个你需要的日志文件名
   
（5）修改hibernate.xml，修改connection.driver_class的值为com.p6spy.engine.spy.P6SpyDriver
（6）重启tomcat
（7）这样在c:/下的spy.log记录了数据库的访问情况。

从初步分析来说，应该是hibernate解释hbm.xml时花费时间，或者可能是spring容器启动并解释所有的bean配置文件 。诊
断了一下，发现1分钟消耗的时间主要分布在hibernate解释hbm.xml花费5秒；spring容器从启动到解释bean配置文件竟然
花了58秒，真是太嚣张了。当时非常怀疑spring的效率问题。企图从网上搜索相关资料，看看有什么优化措施。

首先是找到了hibernate的启动优化 http://www.hibernate.org/194.html  里面的主要思想是通过将xml序列花到本地的
文件里，每次读取的时候根据情况，从本地文件读取并反序列化，节省了hibernate xml的解析时间。按照这个方式测试了
一下，发现hibernate的启动时间从5秒降低到3秒，但是这个优化对于整个启动过程是杯水车薪的，毫无用处。
下面是hibernate的优化代码：

public Configuration addCachableFile(String xmlFile) throws MappingException {        
        try {
            File file = new File(xmlFile);
            File lazyfile = new File(xmlFile + ".bin");
            org.dom4j.Document doc = null; 
            List errors = new ArrayList();
            if(file.exists() && lazyfile.exists() && file.lastModified()<lazyfile.lastModified()) {
                log.info("Mapping lazy file: " + lazyfile.getPath());
                ObjectInputStream oip = null;
                oip = new ObjectInputStream(new FileInputStream(lazyfile));
                doc = (org.dom4j.Document) oip.readObject();
                oip.close(); 
            } else {
                doc = xmlHelper.createSAXReader(xmlFile, errors, entityResolver).read( file );
                log.info("Writing lazy file to " + lazyfile);
                ObjectOutputStream oup = new ObjectOutputStream(new FileOutputStream(lazyfile));
                oup.writeObject(doc);
                oup.flush();
                oup.close();
            }
            
            if ( errors.size()!=0 ) throw new MappingException( "invalid mapping", (Throwable) errors.get(0) );
            add(doc);
            return this;
        }
        catch (Exception e) {
            log.error("Could not configure datastore from file: " + xmlFile, e);
            throw new MappingException(e);
        }
    }

 
不过在运行期间第一次点页面的时候，由于spring做了lazy-load，现在就需要启动一部分需要的beans，所以稍微慢2－3
 秒钟，但是明显比等几十秒要快很多，值得一鉴。

 以上是针对开发阶段的spring容器启动优化，在部署到实际环境中，倒是没必要设置为lazy-load。毕竟部署到实际环境
 中不是经常的事，每次启动1分钟倒不是大问题。

我这里要提醒的是不是说有的beans都能设置default-lazy-init成为true.对于scheduler的bean不能用lazy-init

< beans  default-lazy-init ="true" >   
     < bean  class ="org.springframework.scheduling.quartz.SchedulerFactoryBean" > 
         < property  name ="triggers" > 
             < list > 
                 < ref  bean ="buildHtmlTrigger" /> 
                 < ref  bean ="askTrigger" /> 
                 < ref  bean ="mailSenderTrigger" /> 
                 < ref  bean ="topicDetailBuildTrigger" /> 
                 < ref  bean ="forumBuildTrigger" /> 
                 < ref  bean ="topicBuildTrigger" /> 
             </ list > 
         </ property > 
     </ bean > 
</ beans > 

< beans >  
     < bean  class ="org.springframework.scheduling.quartz.SchedulerFactoryBean" > 
         < property  name ="triggers" > 
             < list > 
                 < ref  bean ="buildHtmlTrigger" /> 
                 < ref  bean ="askTrigger" /> 
                 < ref  bean ="mailSenderTrigger" /> 
                 < ref  bean ="topicDetailBuildTrigger" /> 
                 < ref  bean ="forumBuildTrigger" /> 
                 < ref  bean ="topicBuildTrigger" /> 
             </ list > 
         </ property > 
     </ bean > 
</ beans > 

A special package for ANTLR-generated parser classes.

NOTE: The classes in this package are generated from the ANTLR grammar files, do not register them into version control.

）才明白，原来他的代码是由Antlr产生的。按照要求

1， 配置ANtlr， 将antlr.jar拷贝到jdk的lib下边。, 懒得写配置环境，直接拷贝到JDK的lib下方便。

2， 开始生成java 文件

 到源码的grammar下看到有3个.g文件，首先运行>java antlr.Tool hql.g

接着运行>java antlr.Tool hql-sql.g

最后运行>java antlr.Tool sql-gen.g

OK，关于HSQL的源码生成完毕，拷贝到org.hibernate.hql.antlr包下即可。

关于ANTLR的信息可以参考他的官方网站

http://www.antlr.org/

1、outer-join关键字(many-to-one的情况)

outer-join关键字有3个值，分别是true,false,auto,默认是auto。
true: 表示使用外连接抓取关联的内容，这里的意思是当使用load(OrderLineItem.class,"id")时，Hibernate只生成一条SQL语句将OrderLineItem与他的父亲Order全部初始化。

select * from OrderLineItem o left join Order p on o.OrderId=p.OrderId  where o.OrderLineItem_Id=?

false:表示不使用外连接抓取关联的内容，当load(OrderLineItem.class,"id")时，Hibernate生成两条SQL语句，一条查询OrderLineItem表，另一条查询Order表。这样的好处是可以设置延迟加载，此处要将Order类设置为lazy=true。

select * from OrderLineItem o where o.OrderLineItem_Id=?
select * from Order p where p.OrderId=?

auto:具体是ture还是false看hibernate.cfg.xml中的配置

注意：如果使用HQL查询OrderLineItem，如 from OrderLineItem o where o.id='id'，总是不使用外部抓取，及outer-join失效。

2、outer-join(集合)

由于集合可以设置lazy="true"，所以lazy与outer-join不能同时为true，当lazy="true"时，outer-join将一直是false，如果lazy="false"，则outer-join用法与1同

3、HQL语句会将POJO配置文件中的关联一并查询，即使在HQL语句中没有明确join。

4、In HQL, the "fetch join" clause can be used for per-query specific outer join fetching. One important thing many people miss there, is that HQL queries will ignore the outer-join attribute you specified in your mapping. This makes it possible to configure the default loading behaviour of session.load() and session.get() and of objects loaded by navigating relationship. So if you specify

and then do

MyObject obj = session.createQuery("from MyObject").uniqueResult();

obj.getMySet().iterator().next();

you will still have an additional query and no outer-join. So you must explicily request the outer-join fetching:

MyObject obj = session.createQuery(

"from MyObject mo left join fetch mo.mySet").uniqueResult();

obj.getMySet().iterator().next();

Another important thing to know is that you can only fetch one collection reference in a query. That means you can just use one fetch join. You can however fetch "one" references in addition, as this sample from the Hibernate Docs demonstrates:

from eg.Cat as cat

inner join fetch cat.mate

left join fetch cat.kittens

We have once considered lifting this limitation, but then decided against it, because using more than one fetch-join would be a bad idea generally: The generated ResultSet becomes huge and is a major performance loss.

So alltogether the "fetch join" clause is an important instrument Hibernate users should learn how to leverage, as it allows tuning the fetch behaviour of a certain use case.

5、join fetch 与 join 的区别

如果HQL使用了连接，但是没有使用fetch关键字，则生成的SQL语句虽然有连接，但是并没有取连接表的数据，还是需要单独的sql取数据，也就是 select a,b,d...中没有连接表的字段

6、如果集合被声明为lazy=true，在HQL中如果显式的使用 join fetch 则延迟加载失效。

7、在one-to-many的one端显式设置fecth="join",则无论如何都采取预先抓取（生成一个SQl），延迟加载失效(生成两个SQL)

8、many-to-one的延迟加载是在配置文件的class标签设置lazy="true",one-to-many和many-to- many的延迟加载是在set标签中设置lazy="true"。而one-to-one不只要在calss标签设置lazy="true",而且要在 one-to-one标签中设置constrained="true".

最近结束了一个小型网站项目，主要功能就是一个文章系统，为了提升站点性能，我在首页上使用了OSCache，在访问首页时，性能的确有不小的提升(具体数据见《JMeter小实验——JSP性能简单测试》)，但我对此并不满足，打算使用Hibernate的二级缓存来优化访问文章和栏目时的速度。
        Hibernate的二级缓存有很多选择，我选择了默认的EHCache。它的配置十分简单，只要在Hibernate配置里加入

hibernate.cache.provider_class = net.sf.hibernate.cache.EhCacheProvider

然后在Classpath里加入EHCache.xml文件，我的文件内容如下：

< ehcache >
     < diskStore path = " java.io.tmpdir " />
     < defaultCache
        maxElementsInMemory = " 1000 "
        eternal = " false "
        timeToIdleSeconds = " 600 "
        timeToLiveSeconds = " 600 "
        overflowToDisk = " false "
         />
</ ehcache >

        JavaEye上的《hibernate二级缓存攻略》对这些属性有如下说明：

eternal表示缓存是不是永远不超时

timeToLiveSeconds是缓存中每个元素(这里也就是一个POJO)的超时时间，如果eternal = " false " ，超过指定的时间，这个元素就被移走了。

timeToIdleSeconds是发呆时间，是可选的。当往缓存里面put的元素超过500个时，如果overflowToDisk = " true " ，就会把缓存中的部分数据保存在硬盘上的临时文件里面。

注意：我的配置中最大元素设成了1000。
        如果希望每个缓存的POJO有自己的配置，可以把defaultCache换成cache name="com.xxx.pojo.Foo"。
        完成了EHCache.xml的配置，接下来在每个要被缓存的POJO映射 文件里加入

< cache usage = " read-write "   />

其中read-write是缓存策略，Hibernate还有read-only、nonstrict-read-write和transactional这些策略以供选择。
        配置完成后，我用JMeter测试，发现头两次访问的时间很长，但随后的访问速度有很大提升，数字上相差两位呢。虽然在实际使用时还有网络等因素会影响站点的访问，不过总的来说对于这样的小型文章系统，二级缓存的使用还是对整体性能有帮助的。最后要做的就是根据实际使用情况，适当调整一下缓存设置，我用SpringAOP建立了一个处理日志的拦截器，记录访问量和访问间隔，先让它运行一段时间，随后根据日志情况对缓存作调整。

二.扩展的java类.实现了hibernate的IdentifierGenerator和Configurable

package com.hello.test.po;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import org.hibernate.HibernateException;
import org.hibernate.MappingException;

import org.hibernate.dialect.Dialect;

import org.hibernate.engine.SessionImplementor;

import org.hibernate.id.Configurable;
import org.hibernate.id.IdentifierGenerator;
import org.hibernate.id.PersistentIdentifierGenerator;

import org.hibernate.type.Type;

import java.io.Serializable;

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

import java.util.Date;
import java.util.HashMap;
import java.util.Map;
import java.util.Properties;
import java.util.Properties;

public class InMemoryIncrement implements IdentifierGenerator, Configurable {
    private static final Log log = LogFactory.getLog(InMemoryIncrement.class);

    //存储最大值的数组的容量
    private static final int MAX_CAPACITY = 2000;

    /**同步锁*/
    private static final Object lock = new Object();

    //存储表存储在数组中的索引值
    private static Map map = new HashMap();

    //最大值数组
    private static long[] seqs = new long[MAX_CAPACITY];

    //最大值数组已经使用的容量
    private static int lastIndex;

    //递增步长，默认加1
    private int step = 1;
    private String key;
    private String sql;
    private Connection connection;
    private Class returnClass;

    public Serializable generate(SessionImplementor session, Object object)
        throws HibernateException {
        // TODO Auto-generated method stub
        connection = session.connection();

        long seq = -1;

        //找到索引值
        int index = findIndex();

        //把最大值加1
        seqs[index] = seqs[index] + step;

        seq = seqs[index];
       
        //得到流水号,是自己写的工具类生成的.形式为000x
        String seqStr = JspFormate.currentFormateORM(seq);
        //得到yymmdd,是自己写的方法工具类生成的yymmdd
        String preDate = JspFormate.dateFormateYYYYMMDD(new Date()).substring(2);
        //得到hhmmss,是自己写的工具类获取的hhmmss
        String preHour = JspFormate.dateFormateOnlyHHMMSSORM(new Date());

        return preDate + preHour + seqStr;
    }

    /**
     * 找到表中自动增长字段存储在数组中的索引值
     * @return 索引值
     */
    private int findIndex() {
        int index = 0;

        //首先中缓存中取出索引值
        Integer integer = (Integer) map.get(key);

        //如果没有找到就从数据库中读出最大值并进行cache
        if (null == integer) {
            //double check lock
            synchronized (lock) {
                integer = (Integer) map.get(key);

                if (null == integer) {
                    long maxvalue = 1;

                   /* try {
                        maxvalue = getMaxvalue();
                    } catch (SQLException e) {
                        log.error(e);
                    }*/
                    maxvalue = new Long(0).longValue();

                    integer = new Integer(lastIndex++);
                    seqs[integer.intValue()] = maxvalue;
                    map.put(key, integer);
                }
            }
        }

        index = integer.intValue();

        return index;
    }

    public void configure(Type type, Properties params, Dialect d)
        throws MappingException {
        //     取出table参数
        String table = params.getProperty("table");

        if (table == null) {
            table = params.getProperty(PersistentIdentifierGenerator.TABLE);
        }

        //取出column参数
        String column = params.getProperty("column");

        if (column == null) {
            column = params.getProperty(PersistentIdentifierGenerator.PK);
        }

        //表的sehcma参数
        String schema = params.getProperty(PersistentIdentifierGenerator.SCHEMA);

        returnClass = type.getReturnedClass();

        //取出step参数
        String stepvalue = params.getProperty("step");

        if ((null != stepvalue) && !"".equals(stepvalue.trim())) {
            try {
                step = Integer.parseInt(stepvalue);
            } catch (Exception e) {
                log.error(e);
            }
        }

        //构造存储在Map中的索引值的key name
        key = table + "_$_" + column;

        //根据参数构造取最大值的SQL
        sql = "select max(" + column + ") from ";

        if (null != schema) {
            sql += (schema + ".");
        }

        sql += table;
    }

    /**
     * 取指定表中id字段的最大值，不存在记录返回0
     * @return 最大值
     * @throws SQLException if sql error occurs.
     */
    private long getMaxvalue() throws SQLException {
        long maxvalue = 0;

        PreparedStatement st = connection.prepareStatement(sql);
        System.out.println("============================================" + sql);
        ResultSet rs = null;

        try {
            rs = st.executeQuery();

            if (rs.next()) {
                maxvalue = rs.getLong(1);
            }

            sql = null;
        } finally {
            if (rs != null) {
                rs.close();
            }

            st.close();
        }

        return maxvalue;
    }
}

 1Session session = ;   
 2Transaction tx = ;   
 3  
 4Parent parent = (Parent) session.load(Parent.class, id);   
 5  
 6Child child = new Child();   
 7child.setParent(parent);   
 8child.setName("sun");   
 9  
10parent.addChild(child);   
11s.update(parent);   
12  
13s.flush();   
14tx.commit();   
15s.close();  

在上例中，程序并没有显式的session.save(child); 那么Hibernate需要知道child究竟是一个临时对象，还是已经在数据库中有的持久对象。如果child是一个新创建的临时对象(本例中就是这种情况)，那么Hibernate应该自动产生session.save(child)这样的操作，如果child是已经在数据库中有的持久对象，那么Hibernate应该自动产生session.update(child)这样的操作。

因此我们需要暗示一下Hibernate，究竟child对象应该对它自动save还是update。在上例中，显然我们应该暗示Hibernate对child自动save，而不是自动update。那么Hibernate如何判断究竟对child是save还是update呢？它会取一下child的主键属性 child.getId() ，这里假设id是 java.lang.Integer类型的。如果取到的Id值和hbm映射文件中指定的unsave-value相等，那么Hibernate认为child是新的内存临时对象，发送save，如果不相等，那么Hibernate认为child是已经持久过的对象，发送update。

unsaved-value="null" (默认情况，适用于大多数对象类型主键 Integer/Long/String/...)

当Hibernate取一下child的Id，取出来的是null(在上例中肯定取出来的是null)，和unsaved-value设定值相等，发送save(child)

当Hibernate取一下child的id，取出来的不是null，那么和unsaved-value设定值不相等，发送update(child)

例如下面的情况：

 1Session session = ;   
 2Transaction tx = ;   
 3  
 4Parent parent = (Parent) session.load(Parent.class, id);   
 5Child child = (Child) session.load(Child.class, childId);   
 6  
 7child.setParent(parent);   
 8child.setName("sun");   
 9  
10parent.addChild(child);   
11s.update(parent);   
12  
13s.flush();   
14tx.commit();   
15s.close();  

 

1<class name="Child" table="child">  
2<id column="id" name="id" type="integer" unsaved-value="null">  
3  <generator class="identity"/>  
4</id>  
5   
6</class>  
7

1unsaved-value="0"

<proprety name="XXX " insert="false" column="XXX">

<property name="totlaprice" formula="(select sum(price) form table)">  //子查询

Session session=sessionFactory.openSession();
Traction tx=null;
try{
 tx=session.beingTraction();
   //开始一个事务
  ..
   //提交一个事务
  tx.commit();
 
}catch(Exception e){
  if(tx!=null)
  tx.rollback()

}finally{
 session.close()
}

public void setXXX( Object o){
 this.o=o;
  //插入业务逻辑代码
 caculate();
  //结束
}

<id name="name" column="name" type="string">
  <generator class="assigned"/>//assigned表示由应用程序赋值
</id>

<version name="version"  column="version" unsaved-value="0"/>  //name不可能为空，所以只能通过version版本控制来表示临时和游离对象

public class Coustom{
  private int ID;
  private String name;
      private Set orders=new HashSet(); //一对多关系中
//access method
 
}
public class Orders{
  private int ID;
  private Coustom coustom;               //多对一中，只有'many'方需要引用one'方,'one'方则不需要知道'many'方
//access method
 
}

<many-to-one name="coustom" column="coustom_id" class="Coustom"      
 cascade="save-update"    //级联保存更新
 not-null="true">

<set name="orders" cascade="save-update">
  <key column="coustom_id"/>
  <one-to-many class="Orders">
</set>

    9: 对象的状态转换

  临时态：不在session缓存中，不在数据库中
  持久态：总是被一个session实例（位于session缓存中），session在清理缓存时，会根据持久化对象属性变化，同步数据库
  游离态：不再session缓存中，保存在数据库中

session的Load&Get:

Load返回游离对象本身,在加载不存在OID对象时报错。
Get返回游离对象的副本拷贝，会立刻访问数据库，在加载不存在OID对象时返回null.

10：聚集映射（组件可嵌套配置）
 对应用程序按照精粒度设计原则，尽量提高代码重用性。对关系数据库尽可能减少表的数量，这样一个表可以对应多个类。

public class coustom{
      private  Long  id;
 private Address homeaddress;
      
}

public class Address{   
 //Address没有OID,因为不需要通过session保存，更新。
  private String city;
  private String street;
  private String zipcode;
     private  String province;
     private  Coustom coustom; //所属的整体类

}

 配置代码：

<component name="homeaddress" class="Address">
<parent name="coustom" />   //指定Address所属的整体类
<property name="street" column="home_street"/>
<property name="city" column="home_city"/>
<property name="province" column="home_province"/>
<property name="zipcode" column="home_zipcode"/>
</component>

二级缓存是SessionFactory级别的全局缓存，它底下可以使用不同的缓存类库，比如ehcache、oscache等，需要设置，二级缓存可以制定大小
，
hibernate.cache.provider_class，我们这里用ehcache，在2.1中就是

hibernate.cache.provider_class = net.sf.hibernate.cache.EhCacheProvider 
如果使用查询缓存，加上 
hibernate.cache.use_query_cache = true

缓存可以简单的看成一个Map，通过key在缓存里面找value。

Class的缓存
对于一条记录，也就是一个PO来说，是根据ID来找的，缓存的key就是ID，value是POJO。无论list，load还是 iterate，只要读出一个对象，都会填充缓存。但是list不会使用缓存，而iterate会先取数据库select id出来，然后一个id一个id的load，如果在缓存里面有，就从缓存取，没有的话就去数据库load。假设是读写缓存，需要设置：
<cache usage="read-write"/>
如果你使用的二级缓存实现是ehcache的话，需要配置ehcache.xml

1 < cache name = " com.xxx.pojo.Foo "  maxElementsInMemory = " 500 "  eternal = " false "  timeToLiveSeconds = " 7200 "  timeToIdleSeconds = " 3600 "  overflowToDisk = " true "   />  
2

其中eternal表示缓存是不是永远不超时，timeToLiveSeconds是缓存中每个元素（这里也就是一个POJO）的超时时间，如果eternal="false"，超过指定的时间，这个元素就被移走了。timeToIdleSeconds是发呆时间，是可选的。当往缓存里面put 的元素超过500个时，如果overflowToDisk="true"，就会把缓存中的部分数据保存在硬盘上的临时文件里面。
每个需要缓存的class都要这样配置。如果你没有配置，hibernate会在启动的时候警告你，然后使用defaultCache的配置，这样多个class会共享一个配置。
当某个ID通过hibernate修改时，hibernate会知道，于是移除缓存。
这样大家可能会想，同样的查询条件，第一次先list，第二次再iterate，就可以使用到缓存了。实际上这是很难的，因为你无法判断什么时候是第一次，而且每次查询的条件通常是不一样的，假如数据库里面有100条记录，id从1到100，第一次list的时候出了前50个id，第二次 iterate的时候却查询到30至70号id，那么30-50是从缓存里面取的，51到70是从数据库取的，共发送1+20条sql。所以我一直认为 iterate没有什么用，总是会有1+N的问题。
（题外话：有说法说大型查询用list会把整个结果集装入内存，很慢，而iterate只select id比较好，但是大型查询总是要分页查的，谁也不会真的把整个结果集装进来，假如一页20条的话，iterate共需要执行21条语句，list虽然选择若干字段，比iterate第一条select id语句慢一些，但只有一条语句，不装入整个结果集hibernate还会根据数据库方言做优化，比如使用mysql的limit，整体看来应该还是 list快。）
如果想要对list或者iterate查询的结果缓存，就要用到查询缓存了

查询缓存
首先需要配置hibernate.cache.use_query_cache=true
如果用ehcache，配置ehcache.xml，注意hibernate3.0以后不是net.sf的包名了

< cache name = " net.sf.hibernate.cache.StandardQueryCache "  
maxElementsInMemory = " 50 "  eternal = " false "  timeToIdleSeconds = " 3600 "  
timeToLiveSeconds = " 7200 "  overflowToDisk = " true " />  
< cache name = " net.sf.hibernate.cache.UpdateTimestampsCache "  
maxElementsInMemory = " 5000 "  eternal = " true "  overflowToDisk = " true " />  

然后
query.setCacheable(true);//激活查询缓存
query.setCacheRegion("myCacheRegion");//指定要使用的cacheRegion，可选
第二行指定要使用的cacheRegion是myCacheRegion，即你可以给每个查询缓存做一个单独的配置，使用setCacheRegion来做这个指定，需要在ehcache.xml里面配置它：
<cache name="myCacheRegion" maxElementsInMemory="10" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="7200" overflowToDisk="true" />
如果省略第二行，不设置cacheRegion的话，那么会使用上面提到的标准查询缓存的配置，也就是net.sf.hibernate.cache.StandardQueryCache

对于查询缓存来说，缓存的key是根据hql生成的sql，再加上参数，分页等信息（可以通过日志输出看到，不过它的输出不是很可读，最好改一下它的代码）。
比如hql：
from Cat c where c.name like ?
生成大致如下的sql：
select * from cat c where c.name like ?
参数是"tiger%"，那么查询缓存的key*大约*是这样的字符串（我是凭记忆写的，并不精确，不过看了也该明白了）：
select * from cat c where c.name like ? , parameter:tiger%
这样，保证了同样的查询、同样的参数等条件下具有一样的key。
现在说说缓存的value，如果是list方式的话，value在这里并不是整个结果集，而是查询出来的这一串ID。也就是说，不管是list方法还是iterate方法，第一次查询的时候，它们的查询方式很它们平时的方式是一样的，list执行一条sql，iterate执行1+N条，多出来的行为是它们填充了缓存。但是到同样条件第二次查询的时候，就都和iterate的行为一样了，根据缓存的key去缓存里面查到了value，value是一串id，然后在到class的缓存里面去一个一个的load出来。这样做是为了节约内存。
可以看出来，查询缓存需要打开相关类的class缓存。list和iterate方法第一次执行的时候，都是既填充查询缓存又填充class缓存的。
这里还有一个很容易被忽视的重要问题，即打开查询缓存以后，即使是list方法也可能遇到1+N的问题！相同条件第一次list的时候，因为查询缓存中找不到，不管class缓存是否存在数据，总是发送一条sql语句到数据库获取全部数据，然后填充查询缓存和class缓存。但是第二次执行的时候，问题就来了，如果你的class缓存的超时时间比较短，现在class缓存都超时了，但是查询缓存还在，那么list方法在获取id串以后，将会一个一个去数据库load！因此，class缓存的超时时间一定不能短于查询缓存设置的超时时间！如果还设置了发呆时间的话，保证class缓存的发呆时间也大于查询的缓存的生存时间。这里还有其他情况，比如class缓存被程序强制evict了，这种情况就请自己注意了。

另外，如果hql查询包含select字句，那么查询缓存里面的value就是整个结果集了。

当hibernate更新数据库的时候，它怎么知道更新哪些查询缓存呢？
hibernate在一个地方维护每个表的最后更新时间，其实也就是放在上面net.sf.hibernate.cache.UpdateTimestampsCache所指定的缓存配置里面。
当通过hibernate更新的时候，hibernate会知道这次更新影响了哪些表。然后它更新这些表的最后更新时间。每个缓存都有一个生成时间和这个缓存所查询的表，当hibernate查询一个缓存是否存在的时候，如果缓存存在，它还要取出缓存的生成时间和这个缓存所查询的表，然后去查找这些表的最后更新时间，如果有一个表在生成时间后更新过了，那么这个缓存是无效的。
可以看出，只要更新过一个表，那么凡是涉及到这个表的查询缓存就失效了，因此查询缓存的命中率可能会比较低。

Collection缓存
需要在hbm的collection里面设置
<cache usage="read-write"/>
假如class是Cat，collection叫children，那么ehcache里面配置
<cache name="com.xxx.pojo.Cat.children"
maxElementsInMemory="20" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="7200"
overflowToDisk="true" />
Collection的缓存和前面查询缓存的list一样，也是只保持一串id，但它不会因为这个表更新过就失效，一个collection缓存仅在这个collection里面的元素有增删时才失效。
这样有一个问题，如果你的collection是根据某个字段排序的，当其中一个元素更新了该字段时，导致顺序改变时，collection缓存里面的顺序没有做更新。

缓存策略

只读缓存（read - only）：把对象的id，即数据索引纳入缓存，但是不把实体数据纳入缓存，有时可能会导致更大的性能消耗。
读 / 写缓存（read - write）: 把数据索引和对象同时纳入到缓存中

不严格的读/写缓存（nonstrict-read-write）：需要更新数据，但是两个事务更新同一条记录的可能性很小，性能比读写缓存好
事务缓存（transactional）：缓存支持事务，发生异常的时候，缓存也能够回滚，只支持jta环境，这个我没有怎么研究过

读写缓存和不严格读写缓存在实现上的区别在于，读写缓存更新缓存的时候会把缓存里面的数据换成一个锁，其他事务如果去取相应的缓存数据，发现被锁住了，然后就直接取数据库查询。
在hibernate2.1的ehcache实现中，如果锁住部分缓存的事务发生了异常，那么缓存会一直被锁住，直到60秒后超时。
不严格读写缓存不锁定缓存中的数据。

使用二级缓存的前置条件
你的hibernate程序对数据库有独占的写访问权，其他的进程更新了数据库，hibernate是不可能知道的。你操作数据库必需直接通过 hibernate，如果你调用存储过程，或者自己使用jdbc更新数据库，hibernate也是不知道的。hibernate3.0的大批量更新和删除是不更新二级缓存的，但是据说3.1已经解决了这个问题。
这个限制相当的棘手，有时候hibernate做批量更新、删除很慢，但是你却不能自己写jdbc来优化，很郁闷吧。
SessionFactory也提供了移除缓存的方法，你一定要自己写一些JDBC的话，可以调用这些方法移除缓存，这些方法是：
void evict(Class persistentClass)
Evict all entries from the second-level cache.
void evict(Class persistentClass, Serializable id)
Evict an entry from the second-level cache.
void evictCollection(String roleName)
Evict all entries from the second-level cache.
void evictCollection(String roleName, Serializable id)
Evict an entry from the second-level cache.
void evictQueries()
Evict any query result sets cached in the default query cache region.
void evictQueries(String cacheRegion)
Evict any query result sets cached in the named query cache region.
不过我不建议这样做，因为这样很难维护。比如你现在用JDBC批量更新了某个表，有3个查询缓存会用到这个表，用evictQueries (String cacheRegion)移除了3个查询缓存，然后用evict(Class persistentClass)移除了class缓存，看上去好像完整了。不过哪天你添加了一个相关查询缓存，可能会忘记更新这里的移除代码。如果你的 jdbc代码到处都是，在你添加一个查询缓存的时候，还知道其他什么地方也要做相应的改动吗？

----------------------------------------------------

总结：
不要想当然的以为缓存一定能提高性能，仅仅在你能够驾驭它并且条件合适的情况下才是这样的。hibernate的二级缓存限制还是比较多的，不方便用jdbc可能会大大的降低更新性能。在不了解原理的情况下乱用，可能会有1+N的问题。不当的使用还可能导致读出脏数据。
如果受不了hibernate的诸多限制，那么还是自己在应用程序的层面上做缓存吧。
在越高的层面上做缓存，效果就会越好。就好像尽管磁盘有缓存，数据库还是要实现自己的缓存，尽管数据库有缓存，咱们的应用程序还是要做缓存。因为底层的缓存它并不知道高层要用这些数据干什么，只能做的比较通用，而高层可以有针对性的实现缓存，所以在更高的级别上做缓存，效果也要好些吧。

终于写完了，好累……