hibernate保存类,session.save();并commit了事务,为啥数据库中没有数据,数据库中自动增长的ID增加了1
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了hibernate保存类,session.save();并commit了事务,为啥数据库中没有数据,数据库中自动增长的ID增加了1相关的知识,希望对你有一定的参考价值。
public class HibernateUtil
private static SessionFactory sessionFactory;
static
try
sessionFactory = new Configuration().configure().buildSessionFactory();
catch(Exception ex)
ex.printStackTrace();
public static Session openSession()
Session session = sessionFactory.openSession();
return session;
public static void close(Session session)
if(null != session)
session.close();
//添加学生
@Override
public void addStudent(Student student)
Session session = HibernateUtil.openSession();
Transaction tx = session.beginTransaction();
try
session.save(student);
tx.commit();
catch(Exception ex)
if(null != tx)
System.out.println("添加学生脏数据回滚");
tx.rollback();
finally
HibernateUtil.close(session);
控制台每次都打印出“添加学生脏数据回滚”
session.save(一个设值后Entity);
方便的话能否将代码贴出来。追问
控制台输出:
Hibernate: insert into student_tab (student_loginName, student_loginPassword, student_name, student_age, student_sex, student_address, in_schoolDate, examination_date, student_idCardNumber, student_phone, student_email, student_qq, student_introduction, student_state, teacher_id, school_id) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
添加学生脏数据回滚
你这是插入了脏数据,数据库回滚了。数据库里肯定没有值
你看看你设置的字段中是否有不符合要求的数据,比如说主键的产生方式,某些字段不为空等等。
只要是看Student.hbm.xml这个文件和你生成student对象的地方做个对比。
数据库表是通过hibernate自动生成的。session.save(student);的时候student中应该没有脏数据,因为我数据库中除了主键,其他字段都是可以为空的,我试了,就算只插入一个studentName都会回滚。
追答那有可能是你主键的生成方式有问题。你先将表清空,然后运行程序看看。
方便的话,将Student.hbm.xml关于主键的配置和数据库中主键的配置简要的说明一下。
晕,代码太多,图片也不能插入,能给个邮箱或者QQ,我把代码发过去,我已经搞了2天这个问题了,就这个学生类不能添加,其他模块我也是这么做的,就能正常添加。我的邮箱zxsqq@163.com
追答xkqw205@163.com 有时间帮你看一下。
参考技术A 事务回滚了 你没catch 所以没有报错 参考技术B 首先,检查这个sutdent对象中是否有数据。然后检查hibernate映射文件中映射的数据库列是否跟student实体bean一一对应。如果都检查正确了,那就要看控制台输出的时候报什么错。针对具体的错误来检查问题所在。 参考技术C 事务对象未创建Hibernate深入浅出持久层操作——数据保存&批量操作
数据保存:
1)session.save
session.save方法用于实体对象到数据库的持久化操作。也就是说,session.save方法调用与实体对象所匹配的Insert SQL,将数据插入库表。
结合一个简单实例来进行讨论:
1
2
3
4
5
|
TUser user = new TUser(); user.setName( "Luna" ); Transaction tx = session.beginTransaction(); session.save(user); tx.commit(); |
首先,我们创建了一个user对象,并启动事务,之后调用session.save方法对对象进行保存。
session.save方法中包含了以下几个主要步骤:
a. 在session内部缓存中寻找待保存对象
内部缓存命中,则认为此数据已经保存(执行过insert操作),实体对象已经处于Persistent状态,直接返回。
此时,即使数据相对之前状态已经发生了变化,也将在稍后的事务提交时,由脏数据检查过程加以判定,并根据判定结果决定是否要执行对应的update操作。
b. 如果实体类实现了Lifecycle接口,则调用待保存对象的onSave方法
c. 如果实体类实现了Validatable接口,则调用其validate方法
d. 调用对应拦截器的Interceptor.onSave方法(如果有的话)
e. 构造Insert SQL,并加以执行
f. 记录插入成功,user.id属性被设定为insert操作返回的新记录id值
g. 将user对象放入内部缓存
这里值得一提的是,save方法并不会把实体对象纳入二级缓存,因为通过save方法保存的实体对象,在事务的剩余部分中被修改几率往往很高,缓存的频繁更新以及随之而来的数据同步问题的代价,已经超过了此数据得到重用的可能收益,得不偿失。
h. 最后,如果存在级联关系,对级联关系进行递归处理。
2)session.update
示例:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
TUser user = new TUser(); user.setName(“Emma”); //此时user处于Transient状态 Transaction tx = session.beginTransaction(); session.save(user); //user对象已经由Hibernate纳入管理容器,处于Persistent状态 tx.commit(); session.close(); //user对象此时状态为Detached,因为与其关联的session已经关闭 Transaction tx2 = session2.beginTransaction(); session2.update(user); //处于Detached状态的user对象再次借助session2由Hibernate纳入管理容器, //恢复Persistent状态 user.setName(“Emma_1”); //由于user对象再次处于Persistent状态,因此其属性变更将自动由 //Hibernate固化到数据库中 tx2.commt(); |
这里我们通过update方法将一个Detached状态的对象与session重新关联起来,从而使之转变为Persistent状态。
那么update方法中,到底进行了怎样的操作完成这一步骤?
a. 首先,根据待更新实体对象的Key,在当前session的内部缓存中进行查找,如果发现,则认为当前实体对象已经处于Persistent状态,返回。
从这一点我们可以看出,对一个Persistent状态的实体对象调用update语句并不会产生任何作用。
b. 初始化实体对象的状态信息(作为之后脏数据检查的依据),并将其纳入内部缓存。注意这里session.update方法本身并没有发送Update SQL完成数据更新操作,Update SQL将在之后的session.flush方法中执行(Transaction.commit在真正提交数据库事务之前会调用session.flush)。
3)session.saveOrUpdate
幕后原理:
a. 首先在session内部缓存中进行查找,如果发现则直接返回。
b. 执行实体类对应的Interceptor.isUnsaved方法(如果有的话),判断对象是否为未保存状态。
c. 根据unsave-value判断对象是否处于未保存状态。
d. 如果对象未保存(Transient状态),则调用save方法保存对象。
e. 如果对象已保存(Detached状态),调用update方法将对象与session重新关联。
可以看到,saveOrUpdate实际上是save和update方法的组合应用。它本身并没有增加新的功能特性,但为应用层开发提供了一个为相当边界的功能选择。
有了saveOrUpdate方法,处理就相当简单明了,我们无需关心传入的user参数到底是怎样的状态。
数据批量操作:
显然,最简单的方式就是通过迭代调用
session.save/update/saveOrUpdate/delete操作。从逻辑上而言,这样的解决方式并没有什么问题。不过,从性能角度考虑,这样的做法却有待商榷。
1. 数据批量导入
举个简单的例子,我们需要导入10万个用户数据。那么,对应我们实现了相应的数据批量导入方法:
1
2
3
4
5
6
7
8
9
|
public void importUsers() throws HibernateException{ Transaction tx = session.beginTransaction(); for ( int i= 0 ;i< 100000 ;i++){ TUser user = new TUser(); user.setName(“user”+i); session.save(user); } tx.commit(); } |
代码从逻辑上看并没有什么问题。但是运行期可能就会发现,程序运行由于OutOfMemoryError而异常中止。
why?原因在于Hibernate内部缓存的维护机制,每次调用
session.save方法时,当前session都会将此对象纳入自身的内部缓存进行管理。
内部缓存与二级缓存不同,我们可以在二级缓存的配置中指定其最大容量,但内部缓存并没有这样的限制。
随着循环的进行,越来越多的TUser实例被纳入到session内部缓存之中,内存逐渐耗尽,于是产生了OutOfMemoryError。
如何避免这样的问题?
一个解决方案是每隔一段时间清空session内部缓存,如:
1
2
3
4
5
6
7
8
9
10
11
|
Transaction tx = session.beginTransaction(); for ( int i= 0 ;i< 100000 ;i++){ TUser user = new TUser(); user.setName(“user”+i); session.save(user); if (i% 25 == 0 ){ //以每25个数据作为一个处理单元 session.flush(); session.clear(); } } tx.commit(); |
在传统JDBC编程时,对于批量操作,一般用怎样的方式加以优化?
下面的代码是一个典型的基于JDBC的改进实现:
1
2
3
4
5
6
|
PreparedStatement stmt = conn.prepareStatement(“INSERT INTO t_user(name) VALUES(?)”); for ( int i= 0 ;i< 100000 ;i++){ stmt.setString( 1 ,”user”+i); stmt.addBatch(); } int [] counts = stmt.executeBatch(); |
这里我们通过PreparedStatement.executeBacth方法,将数个SQL操作批量提交以获得性能上的提升。
那么Hibernate中是否有对应的批量操作方式呢?
我们可以通过设置hibernate.jdbc.batch_size参数来指定Hibernate每次提交SQL的数量:
1
2
3
4
5
6
7
|
< hibernate-mapping > < session-factory > … < property name=”hibernate.jdbc.batch_size”>25</ property > … </ session-factory > </ hibernate-mapping > |
这样,当我们发起SQL调用的时候,Hibernate会累积到25个SQL之后批量提交,从而实现了与上面JDBC代码类似的效能。
同样的方法,也可以用于Update操作和Delete操作。
下面做个简单的测试,看看hibernate.jdbc.batch_size参数对于批量插入操作的实际影响。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
public void importUserList() throws HibernateException{ Transaction tx = session.beginTransaction(); for ( int i= 0 ;i< 100000 ;i++){ TUser user = new TUser(); user.setName(“user”+i); session.save(user); if (i% 25 == 0 ){ //以每25个数据作为一个处理单元 session.flush(); session.clear(); } } tx.commit(); } public void testBatchInsert(){ long startTime = System.currentTimeMillis(); try { this .importUserList(); } catch (HibernateException e){ e.printStackTrace(); } long currentTime = System.currentTimeMillis(); System.out.println(“Batch Insert Time cost in ms => “+(currentTime-startTime)); } |
测试环境:
操作系统:XP sp2
JDK版本:Sun JDK 1.4.2_08
CPU: p4 1.5G Mobile
RAM:512M
数据库:SQLServer2000/Oracle9i
JDBC:jtds JDBC Driver for SQLServer 1.02/Oracle JDBC Driver 9.0.2.0.0
注:Mysql JDBC Driver不支持BatchUpdate方式,因此batch_size的设定对MySQL无效。
对于远程数据库,hibernate.jdbc.batch_size的设定就相当关键。
这里的差距,并不是数据存取机制有什么不同,而是在于网络传输上的损耗,对于数据库与应用均部署在本机的情况而言,数据通讯上的性能损耗较小,因而hibernate.jdbc.batch_size设定的影响相对较弱,而对于远程数据库,网络传输上的损耗就不可不计,因而不同的传输模式(批量传输与单笔传输)将对性能的整体表现产生较大影响。
2. 数据批量删除
批量删除操作在Hibernate2和Hibernate3中有着不同的实现机制,首先来看Hibernate2中的批量删除。
下面是一段典型的Hibernate2批量删除代码:
1
2
3
|
Transaction tx = session.beginTransaction(); session.delete(“from TUser”); tx.commit(); |
(假设数据库t_user表中有1000条记录)
对于这样的代码,Hibernate会执行以下语句:
Hibernate会首先从数据库查询出所有符合条件的记录,再对此记录进行循环删除,实际上,session.delete(“from TUser”)等价于:
1
2
3
4
5
6
7
|
Transaction tx = session.beginTransaction(); List userList = session.find(“from TUser”); int len = userList.size(); for ( int i= 0 ;i<len;i++){ session.delete(userList.get(i)); } tx.commit(); |
实际上,Hibernate内部,Delete方法的实现也正是如此,如下:
1
2
3
4
5
6
7
8
9
10
11
12
|
public int delete(String query, Object[] values, Type[] types) throws HibernateException{ if (log.isTraceEnabled()){ log.trace(“delete: ”+query); if (values.length!= 0 ) log.trace(“parameters: “+ StringHelper.toString(values)); } List list = find(query,values,types); int size = list.size(); for ( int i= 0 ;i<size;i++) delete(list.get(i)); return size; } |
看上去很难以理解的实现方式,为什么Hibernate不单独执行一条Delete SQL”delete t_user where id>5”完成所有的工作呢?
这就是所有ORM框架都必须面对的问题。ORM为了自动维持其内部状态属性,必须知道用户到底对哪些数据进行了操作。它必须首先从数据中获得所有待删除对象,才能根据这些对象,对目前内部缓存和二级缓存中的数据进行整理,以保持内存状态与数据库数据的一致性。
当然,解决办法并不是没有,ORM可以根据调用的Delete SQL对缓存中的数据进行处理,只要是缓存中TUser对象的id值大于5的统统废除,缓存数据废除之后,再执行”delete from t_user where id>5”.但是,如此的需求将导致缓存的管理复杂性大大增加(实际上是实现了一个支持SQL的内存数据库),这样的要求对于一个轻量级的ORM实现而言未免苛刻。
批量删出操作同样会遇到与数据批量导入操作同样的问题:
1) 内存消耗
对于内存消耗问题,无法像之前一样通过session.clear操作解决,因为我们并无法干涉数据的批量加载过程。
变通的方法之一:用session.iterate或者Query.iterate方法逐条获取数据,再执行delete操作。
另外,Hibernate2.16之后的版本提供了基于游标的数据遍历操作,为解决这个问题提供了一个较好的解决方案(前提是所使用的JDBC驱动必须支持游标)。通过游标,我们可以逐条获取数据,从而使得内存处于较为稳定的使用状态。
下面是基于游标的Hibernate批量删除示例:
1
2
3
4
5
6
7
8
9
|
Transaction tx = session.beginTransaction(); String hql = “from TUser”; Query query = session.createQuery(hql); ScrollableResults scRes = query.scroll(); while (scRes.next()){ TUser user = (TUser)scRes.get( 0 ); session.delete(user); } tx.commit(); |
2) 迭代删除操作的执行效率
由于Hibernate批量删除操作过程中,需要反复调用delete SQL,因此同样存在SQL批量发送问题,对于这个问题,我们仍采用调整hibernate.jdbc.batch_size参数解决。
使用JDBC代码测试:
1
2
3
|
String sqlStr = “delete from t_user”; Statement statement = dbconn.createStatement(); statement.execute(sqlStr); |
耗时:390ms。
可以看到,即使是优化过的批量删除功能,性能差距还是相当可观的(近10倍的差距)。因此,在Hibernate2中,对于批量操作而言,适当的时候采用传统的JDBC进行直接的批量数据库操作(此时应特别注意对缓存的影响),可以获得性能上的极大提升,特别是对于批量性能关键的逻辑实现而言。
考虑到以上问题,Hibernate3 HQL语法中引入了bulk delete/update操作,bulk delete/update操作的原理,即通过一条独立的SQL语句完成数据的批量删除/更新操作(类似上例中的JDBC批量删除)。
我们可以通过如下代码删除t_user表中的所有记录:
1
2
3
4
5
6
|
Transaction tx = session.beginTransaction(); String hql = “delete from t_user”; Query query = session.createQuery(hql); int ret = query.executeUpdate(); tx.commit(); System.out.println(“delete records =>”+ret); |
观察运行期日志输出:
可以看到,通过一条干净利落的”delete from t_user”语句,我们即完成数据的批量删除功能,从底层实现来看,这与之前JDBC示例中的实现方式并没有什么不同,性能表现也大致相似。
那么,我们之前曾谈及的批量删除与缓存管理上的矛盾,在Hibernate3中是否仍然存在?
这也正是必须特别注意的一点,Hibernate3的bulk delete/update实际上仍然没有解决缓存同步上的问题,无法保证缓存数据的一致有效性。
看以下示例:
1
2
3
4
5
6
7
8
9
10
|
//加载id=1的用户记录 TUser user = (TUser)session.load(TUser. class , new Integer( 1 )); System.out.println(“User name is ==> “+user.getName()); //删除id=1的用户记录 Transaction tx = session.beginTransaction(); session.delete(user); tx.commit(); //尝试再次加载 user = (TUser)session.load(TUser. class , new Integer( 1 )); System.out.println(“User name is ==> “+user.getName()); |
尝试运行以上代码,在尝试再次加载已删除的TUser对象时,Hibernate将抛出ObjectDeletedException,表明此对象已删除,加载失败。
将以上代码修改为通过bulk delete/update删除的形式:
1
2
3
4
5
6
7
8
9
10
11
12
|
//加载id=1的用户记录 TUser user = (TUser)session.load(TUser. class , new Integer( 1 )); System.out.println(“User name is ==> “+user.getName()); //通过bulk delete/update删除id=1的用户记录 Transaction tx = session.beginTransaction(); String hql = “delete from t_user where id= 1 ”; Query query = session.createQuery(hql); query.executeUpdate(); tx.commit(); //尝试再次加载 user = (TUser)session.load(TUser. class , new Integer( 1 )); System.out.println(“User name is ==> “+user.getName()); |
输出日志如下:
可以看到,第二次加载操作成功,由于缓存同步上的问题,我们得到了一个已经被删除的过期数据对象。
通过前面的讨论,我们知道,Hibernate中维护了两级缓存。
上面的代码中,我们通过同一个session实例反复进行数据加载,第二次查询操作将从内部缓存中直接查找数据返回。
那么,在不同session实例之间的协调情况如何,二级缓存中的数据有效性是否能得到保证?
打开Hibernate二级缓存,运行以下代码:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
//加载id=1的用户记录 TUser user = (TUser)session.load(TUser. class , new Integer( 1 )); System.out.println(“User name is ==> “+user.getName()); //加载id=1的用户记录已被放入二级缓存 //通过bulk delete/update删除id=1的用户记录 Transaction tx = session.beginTransaction(); String hql = “delete from t_user where id= 1 ”; Query query = session.createQuery(hql); query.executeUpdate(); tx.commit(); //通过另一个session实例再次尝试加载 user = (TUser)anotherSession.load(TUser. class , new Integer( 1 )); System.out.println(“User name is ==> “+user.getName()); |
在尝试再次加载已删除数据对象时,我们调用了另一个session实例。
运行日志输出如下:
可以看到,与前例相同,第二次数据加载时Hibernate依然返回了无效数据。
也就是说,bulk delete/update只是提供了面向高性能批量操作的一种实现途径,但无法保证缓存数据的一致有效性,在实际开发中,必须特别注意这一点,在缓存策略的制定上须特别谨慎。
数据的批量更新与批量删除相关知识点基本相同,就不再赘述。
为此牺牲的所谓设计上的优雅性,未必就那么令人惋惜。毕竟对于应用系统的开发而言,为客户提供一个满足需求并且高效稳定的系统才是第一目标,产品最终能得到用户的欢迎,才是真正的优雅。
以上是关于hibernate保存类,session.save();并commit了事务,为啥数据库中没有数据,数据库中自动增长的ID增加了1的主要内容,如果未能解决你的问题,请参考以下文章
如何使用 Hibernate session.save() 插入/保存对象而不更新旧记录
hibernate中 session.save(实体类)方法的原理
hibernate的save方法与sql的insert的区别