不同的数据源，不同的数据操作流程——记录下最近的项目心得

最近在做一个很简单的小项目，虽然简单，但也遇到了不少的问题，现在大致记录一下：

这个项目基本上分为两大模块：

一是我做的这一块，用现在通用的SSH框架维护两张表，一张用户表，一张账户表，两张表没有任何关联，一切都很顺利。

二是一个同事做的另外一个模块，是一个计时器任务，设置一个固定的时间间隔，每隔这个时间段就会执行一次这个任务，进行的也很顺利。

但当我们两个集成的时候问题来了，我在前台页面添加的数据他那边hold不住，只在刚启动的时候能够查询到数据表中数据，我在这边新添加的数据一律查询不到，找了很长时间才发现:原来是数据源的问题，我用了一个数据源，他用了一个数据源，我们两个用了两个数据源，所以才会出现这样的不同步，这样通过修改Spring配置，把我的数据源注入给他后，这才暂时解决了这个问题。现在我这边新添加的数据他那边能够查询到了，算是解决了，昨天晚上搞到八点多才弄好。不过今天早上再次试运行，又发现了新的问题，他那边是一个计时器任务，动态维护数据表，当表中的数据不再满足要求时会把它删掉，但是我前台这时候页面上还显示了已经删掉的数据，因为没刷新嘛，现在显示也正常，如果正常的走下去，应该是我一刷新就会只显示数据库中有的数据，可事实并不是这样，一刷新直接报错：No row with the given identifier exists

在网上找了相关的资料，如下所示：

Hibernate中No row with the given identifier exists问题的原因及解决

            产生此问题的原因:

             有两张表,table1和table2.产生此问题的原因就是table1里做了关联<one-to-one>或者<many-to-one unique="true">(特殊的多对一映射,实际就是一对一)来关联table2.当hibernate查找的时候,table2里的数据没有与table1相匹配的,这样就会报No row with the given identifier exists这个错.(一句话,就是数据的问题!)

           假如说,table1里有自身的主键id1,还有table2的主键id2,这两个字段.

          如果hibenrate设置的单项关联,即使table1中的id2为null值,table2中id2中有值,查询都不会出错.但是如果table1中的id2字段有值,但是这个值在table2中主键值里并没有,就会报上面的错!

         如果hibernate是双向关联,那么table1中的id2为null值,但是table2中如果有值,就会报这个错.这种情况目前的解决办法就是改成单项关联,或者把不对应的数据改对!

           这就是报这个错的原因了,知道原因了就相应的改就行了.或许还有些人迷惑hibernate关联都配好了,怎么会出现这样的错?其实这是编程的时候出现的问题,假如说我在添加信息的时候,页面传过来的struts的formbean到dao方法中需要封装成hibernate的po(就是hibenrate的bean),要是一个个po.get(form.set())实在太麻烦了,这样一般都会写个专门的方法来封装,遇到po.get(form.set())这种情况直接把struts的formbean对象传到此方法中封装就行了,假如我有个字段是创建人id,那么这个字段是永远不会改的,我在添加的时候还调用这个方法,这个专门封装的方法是有一些判断的,假如说我判断一下,如果遇到创建人id传过来为空值,我判断如果是空值,我把创建人id设为0,但是用户表中userid是主键从1开始自增的,那么这样数据就对应不上了,一查就会出这个错了.这个错在开发刚开始的时候经常发生,因为每个人的模块都是由相应的人独立开发完成以后再整合在一起的,每个人写单独那一块的时候往往会忽略这些,所以整合的时候这些问题往往就都一下子全冒出来了....整合很辛苦,tnnd!

 

 

hibernate的查询的比较
hibernate的查询有很多,Query,find,Criteria,get,load

query使用hsql语句，可以设置参数是常用的一种方式

criteria的方式，尽量避免了写hql语句，看起来更面向对象了。

find方式，这种方式已经被新的hibernate丢弃

get和load方式是根据id取得一个记录
下边详细说一下get和load的不同，因为有些时候为了对比也会把find加进来。

1，从返回结果上对比：
load方式检索不到的话会抛出org.hibernate.ObjectNotFoundException异常
get方法检索不到的话会返回null

2，从检索执行机制上对比：
get方法和find方法都是直接从数据库中检索
而load方法的执行则比较复杂
1,首先查找session的persistent Context中是否有缓存，如果有则直接返回
2,如果没有则判断是否是lazy，如果不是直接访问数据库检索，查到记录返回，查不到抛出异常
3,如果是lazy则需要建立代理对象，对象的initialized属性为false，target属性为null
4, 在访问获得的代理对象的属性时,检索数据库，如果找到记录则把该记录的对象复制到代理对象的target
上，并将initialized=true，如果找不到就抛出异常 。

 

情况跟我的很类似，我这边虽然只有一张表，但操作很类似，我这边有一套操作流程，计时器那边也有一套操作流程，计时器那边直接用JDBC操作数据库，我用的Hibernate操作数据库，由于Hibernate有缓存，数据查询出来后，Hibernate里面有相应的缓存记录，计时器那边删掉数据后，前台一刷新就会报上述那样的错误，知道了什么原因，要解决也就很简单了，想办法把Hibernate的缓存停掉，在Hibernate的配置文件hibernate.cfg.xml中有相应的缓存设置：

<?xml version='1.0' encoding='UTF-8'?><!DOCTYPE hibernate-configuration PUBLIC          "-//Hibernate/Hibernate Configuration DTD 3.0//EN"          "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"><!-- Generated by MyEclipse Hibernate Tools.  --><hibernate-configuration><session-factory><property name="dialect">org.hibernate.dialect.MySQLDialect</property><!--  property name="connection.datasource">java:comp/env/MysqlDB</property>--><property name="show_sql">false</property><property name="connection.release_mode">auto</property><!-- cache --><property name="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property><property name="hibernate.cache.use_query_cache">false</property><property name="cache.use_second_level_cache">false</property><property name="query.factory_class">org.hibernate.hql.classic.ClassicQueryTranslatorFactory</property><!-- <property name="query.factory_class">org.hibernate.hql.ast.ASTQueryTranslatorFactory</property>--><property name="format_sql">true</property><property name="use_sql_comments">true</property><mapping resource="config/hibernate/monitor/User.hbm.xml" /><mapping resource="config/hibernate/monitor/Account.hbm.xml" /></session-factory></hibernate-configuration>

其中有两行代码：

<property name="hibernate.cache.use_query_cache">false</property><property name="cache.use_second_level_cache">false</property>

本来的值为true,现在改为false,表示停掉缓存

Hibernate 批量插入、更新与删除

批量插入

在项目的开发过程之中，由于项目需求，我们常常需要把大批量的数据插入到数据库。数量级有万级、十万级、百万级、甚至千万级别的。如此数量级别的数据用Hibernate做插入操作，就可能会发生异常，常见的异常是OutOfMemoryError（内存溢出异常）。

首先，我们简单来回顾一下Hibernate插入操作的机制。Hibernate要对它内部缓存进行维护，当我们执行插入操作时，就会把要操作的对象全部放到自身的内部缓存来进行管理。

谈到Hibernate的缓存，Hibernate有内部缓存与二级缓存之说。由于Hibernate对这两种缓存有着不同的管理机制，对于二级缓存，我们可以对它的大小进行相关配置,而对于内部缓存，Hibernate就采取了“放任自流”的态度了，对它的容量并没有限制。现在症结找到了，我们做海量数据插入的时候，生成这么多的对象就会被纳入内部缓存（内部缓存是在内存中做缓存的），这样你的系统内存就会一点一点的被蚕食，如果最后系统被挤“炸”了，也就在情理之中了。

我们想想如何较好的处理这个问题呢？有的开发条件又必须使用Hibernate来处理，当然有的项目比较灵活，可以去寻求其他的方法。

笔者在这里推荐两种方法：
(1)：优化Hibernate,程序上采用分段插入及时清除缓存的方法。
(2)：绕过Hibernate API ，直接通过 JDBC API 来做批量插入，这个方法性能上是最好的，也是最快的。
对于上述中的方法1，其基本是思路为：优化Hibernate，在配置文件中设置hibernate.jdbc.batch_size参数，来指定每次提交SQL的数量；程序上采用分段插入及时清除缓存的方法(Session实现了异步write-behind，它允许Hibernate显式地写操作的批处理),也就是每插入一定量的数据后及时的把它们从内部缓存中清除掉，释放占用的内存。
设置hibernate.jdbc.batch_size参数，可参考如下配置。

<hibernate-configuration>
<session-factory>
.........
<property name=” hibernate.jdbc.batch_size”>50</property>
.........
<session-factory>
<hibernate-configuration>

配置hibernate.jdbc.batch_size参数的原因就是尽量少读数据库，hibernate.jdbc.batch_size参数值越大，读数据库的次数越少，速度越快。从上面的配置可以看出，Hibernate是等到程序积累到了50个SQL之后再批量提交。

笔者也在想，hibernate.jdbc.batch_size参数值也可能不是设置得越大越好，从性能角度上讲还有待商榷。这要考虑实际情况，酌情设置，一般情形设置30、50就可以满足需求了。
程序实现方面，笔者以插入10000条数据为例子，如

Session session=HibernateUtil.currentSession();
Transatcion tx=session.beginTransaction();
for(int i=0;i<10000;i++)
{
Student st=new Student();
st.setName(“feifei”);
session.save(st);

// 以每50个数据作为一个处理单元
if(i%50==0)
{
// 只是将Hibernate缓存中的数据提交到数据库，保持与数据库数据的同步

session.flush();

// 清除内部缓存的全部数据，及时释放出占用的内存
session.clear();
}
}
tx.commit();
.........

在一定的数据规模下，这种做法可以把系统内存资源维持在一个相对稳定的范围。

注意：前面提到二级缓存，笔者在这里有必要再提一下。如果启用了二级缓存，从机制上讲Hibernate为了维护二级缓存，我们在做插入、更新、删除操作时，Hibernate都会往二级缓存充入相应的数据。性能上就会有很大损失，所以笔者建议在批处理情况下禁用二级缓存。

对于方法2，采用传统的JDBC的批处理，使用JDBC API来处理。

些方法请参照java 批处理自执行SQL

看看上面的代码，是不是总觉得有不妥的地方？对，没发现么！这还是JDBC的传统编程，没有一点Hibernate味道。
可以对以上的代码修改成下面这样：

Transaction tx=session.beginTransaction(); //使用Hibernate事务处理
边界Connection conn=session.connection();
PrepareStatement stmt=conn.prepareStatement(“insert into T_STUDENT(name) values(?)”);
for(int j=0;j++;j<200)...{
for(int i=0;i++;j<50)
...{
stmt.setString(1,”feifei”);
}
}
stmt.executeUpdate();
tx.commit(); //使用 Hibernate事务处理边界
.........

这样改动就很有Hibernate的味道了。笔者经过测试，采用JDBC API来做批量处理，性能上比使用Hibernate API要高将近10倍，性能上JDBC 占优这是无疑的。

批量更新与删除

Hibernate2中，对于批量更新操作，Hibernate是将符合要求的数据查出来，然后再做更新操作。批量删除也是这样，先把符合条件的数据查出来，然后再做删除操作。
这样有两个大缺点：
(1)：占用大量的内存。
(2)：处理海量数据的时候，执行update/delete语句就是海量了，而且一条update/delete语句只能操作一个对象，这样频繁的操作数据库，性能低下应该是可想而知的了。
Hibernate3 发布后，对批量更新/删除操作引入了bulk update/delete，其原理就是通过一条HQL语句完成批量更新/删除操作，很类似JDBC的批量更新/删除操作。在性能上，比Hibernate2的批量更新/删除有很大的提升。

Transaction tx=session.beginSession();
String HQL=”delete STUDENT”;
Query query=session.createQuery(HQL);
int size=query.executeUpdate();
tx.commit();
.......

控制台输出了也就一条删除语句Hibernate:delete from T_STUDENT,语句执行少了，性能上也与使用JDBC相差无几，是一个提升性能很好的方法。当然为了有更好的性能，笔者建议批量更新与删除操作还是使用JDBC，方法以及基本的知识点与上面的批量插入方法2基本相同，这里就不在冗述。

笔者这里再提供一个方法，就是从数据库端来考虑提升性能，在Hibernate程序端调用存储过程。存储过程在数据库端运行，速度更快。以批量更新为例，给出参考代码。
首先在数据库端建立名为batchUpdateStudent存储过程:

create or replace produre batchUpdateStudent(a in number) as
begin
update STUDENT set AGE=AGE+1 where AGE>a;
end;
调用代码如下：
Transaction tx=session.beginSession();
Connection conn=session.connection();
String pd=”...{call batchUpdateStudent(?)}”;
CallableStatement cstmt=conn.PrepareCall(pd);
cstmt.setInt(1,20); //把年龄这个参数设为20
tx.commit()；

观察上面的代码，也是绕过Hibernate API,使用 JDBC API来调用存储过程，使用的还是Hibernate的事务边界。存储过程无疑是提高批量处理性能的一个好方法，直接运行与数据库端，某种程度上讲把批处理的压力转接给了数据库。

三：编后语
本文探讨了Hibernate的批处理操作，出发点都是在提高性能上考虑了，也只是提供了提升性能的一个小方面。
不管采取什么样的方法，来提升性能都要根据实际的情况来考虑，为用户提供一个满足需求的而且高效稳定的系统才是重中之中。