http://blog.csdn.net/yerenyuan_pku/article/details/70148567

Hibernate的一级缓存

Hibernate的一级缓存就是指Session缓存。通过查看Session接口的实现类——SessionImpl.java的源码可发现有如下两个类: 

  • actionQueue它是一个行动队列,它主要记录crud操作的相关信息。
  • persistenceContext它是持久化上下文,它其实才是真正的缓存。

在Session中定义了一系列的集合来存储数据,它们构成了Session的缓存。只要Session没有关闭,它就会一直存在。当我们通过Hibernate中的Session提供的一些API例如save()、get()、update()等进行操作时,就会将持久化对象保存到Session中,当下一次再去查询缓存中具有的对象(通过OID值来判断),就不会去从数据库中查询了,而是直接从缓存中获取。Hibernate的一级缓存存在的目的就是为了减少对数据库的访问。 
当然了,在Hibernate中还有一个二级缓存,它是SessionFactory级别缓存,我也不明白,所以在这儿,我就不做介绍了。

演示一级缓存的存在

现在我举例来演示一级缓存的存在。首先我们肯定要搭建好Hibernate的开发环境,读过我前面文章的童鞋,应该可以快速搭建好的,在此不做过多赘述。 
在cn.itheima.test包下新建一个单元测试类——HibernateTest.java,我们首先编写如下方法来测试一级缓存的存在:

public class HibernateTest {

    // 测试一级缓存
@Test
public void test3() {
// 1.得到session
Session session = HibernateUtils.openSession();
session.beginTransaction(); Customer customer = session.get(Customer.class, 1); // 查询id=1的Customer对象,如果查询到,会将Customer对象存储到一级缓存中
Customer customer2 = session.get(Customer.class, 1); // 会从一级缓存中查询,而不会向数据库再发送sql语句查询 // 2.事务提交,并关闭session
session.getTransaction().commit();
session.close();
} }

首次查询id为1的Customer对象时,Hibernate会向MySQL数据库发送如下SQL语句:

select
customer0_.id as id1_0_0_,
customer0_.name as name2_0_0_,
customer0_.address as address3_0_0_,
customer0_.sex as sex4_0_0_
from
hibernateTest.t_customer customer0_
where
customer0_.id=?

而第二次查询时,并没有向MySQL数据库发送select语句。这是因为首次查询id为1的Customer对象时,如果查询到,就会将Customer对象存储到一级缓存中,第二次查询时,会从一级缓存中查询,而不会向数据库再发送select语句查询。

持久化对象具有自动更新数据库的能力

现在我举例来演示持久化对象具有自动更新数据库的能力。在HibernateTest单元测试类中编写如下方法:

public class HibernateTest {

    // 持久化对象具有自动更新数据库的能力
@Test
public void test4() {
// 1.得到session
Session session = HibernateUtils.openSession();
session.beginTransaction();
Customer customer = session.get(Customer.class, 1); // 查询id=1的Customer对象,如果查询到,会将Customer对象存到一级缓存中
customer.setName("Tom"); // 操作持久化对象来修改属性
// 2.事务提交,并关闭session
session.getTransaction().commit();
session.close();
} }

测试以上test4方法,将发现数据库t_customer表中,id为1的那条记录的name字段变为Tom,这足以说明持久化对象具有自动更新数据库的能力了。但是为什么持久化对象具有自动更新数据库的能力呢?原因涉及到一个概念——快照,快照就是当前一级缓存里面对象的散装数据(对象的属性,如name、id……)。当执行完以下这句代码:

Customer customer = session.get(Customer.class, 1);

就会向一级缓存中存储数据,一级缓存其底层使用了一个Map集合来存储,Map的key存储的是一级缓存对象,而value存储的是快照。通过在这句代码上打个断点,然后以debug的方式运行,Watch一下session会看得更加清楚,如下: 

接着执行以下这句代码:

customer.setName("Tom");

执行完毕会修改一级缓存中的数据,如下: 

当事务提交,session关闭,向数据库发送请求时,会判断一级缓存中数据是否与快照区一致,如果不一样,就会发送update语句。

一级缓存常用API

一级缓存特点:

  1. 当我们通过session的save、update、saveOrUpdate方法进行操作时,如果一级缓存中没有对象,那么会从数据库中查询到这些对象,并存储到一级缓存中。
  2. 当我们通过session的load、get、Query的list等方法进行操作时,会先判断一级缓存中是否存在数据,如果没有才会从数据库获取,并且将查询的数据存储到一级缓存中。
  3. 当调用session的close方法时,session缓存将清空。

一级缓存常用的API:

  1. clear():清空一级缓存。
  2. evict():清空一级缓存中指定的某个对象。
  3. refresh():重新查询数据库,用数据库中的信息来更新一级缓存与快照区。

现在我举例来演示一级缓存常用的API。在HibernateTest单元测试类中编写如下方法:

public class HibernateTest {

    // 测试一级缓存操作常用的API
@Test
public void test5() {
// 1.得到session
Session session = HibernateUtils.openSession();
session.beginTransaction(); // 操作
List<Customer> list = session.createQuery("from Customer").list(); // 这个操作会存储数据到一级缓存
session.clear(); // 清空一级缓存
Customer c = session.get(Customer.class, 1); // 会先从session的一级缓存中获取,如果不存在,才会从数据库里面获取 session.evict(c); // 从一级缓存中删除一个指定的对象
Customer cc = session.get(Customer.class, 1); cc.setName("kkkk");
session.refresh(cc); // refresh方法的作用是:它会用数据库里面的数据来同步我们的一级缓存以及快照区,
// 这样的话,再操作cc时,就不会发送update语句。
// refresh方法:重新查询数据库,用数据库中的信息来更新一级缓存与快照区 // 2.事务提交,并关闭session
session.getTransaction().commit();
session.close();
} }

可通过debug方式运行,这样会看得更清楚。在此不做过多赘述,读者自行操作。

Hibernate中常用API-Session的补充

讲完Hibernate持久化对象的三种状态和一级缓存之后,我就可以继续深入一点的讲解Session类中的以下方法了。

update

udpate操作主要是针对于脱管对象而言的,因为持久化对象具有自动更新数据库的能力。如果我们直接操作的对象是一个脱管对象,执行update会出现什么情况?如下:

public class HibernateTest {

    // session的update操作
@Test
public void test6() {
// 1.得到session
Session session = HibernateUtils.openSession();
session.beginTransaction(); // 执行update来操作一个脱管对象
Customer c = new Customer();
c.setAddress("天门");
c.setName("赵六");
c.setId(1); // 注意:我这里是为了模拟,所以手动给其赋值ID,正常的实际开发中是不建议这么做的 session.update(c); // 当执行update时,会将c放入到session的一级缓存 // 2.事务提交,并关闭session
session.getTransaction().commit();
session.close();
} }

运行以上test6方法,可以发现数据库t_customer表中id为1的记录已经更新了。得出结论:update操作时,如果操作的对象是一个脱管对象,则可以操作,并且它会将脱管对象转换成持久对象再操作。但是这里依然会引发两个问题:

  1. 如果在session中出现相同的oid的两个对象,会产生如下异常:

    org.hibernate.NonUniqueObjectException: A different object with the same identifier value was already associated with the session : [cn.itheima.domain.Customer#1]
    at org.hibernate.engine.internal.StatefulPersistenceContext.checkUniqueness(StatefulPersistenceContext.java:648)
    at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.performUpdate(DefaultSaveOrUpdateEventListener.java:284)
    at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.entityIsDetached(DefaultSaveOrUpdateEventListener.java:227)
    at org.hibernate.event.internal.DefaultUpdateEventListener.performSaveOrUpdate(DefaultUpdateEventListener.java:38)
    at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:73)
    at org.hibernate.internal.SessionImpl.fireUpdate(SessionImpl.java:703)
    at org.hibernate.internal.SessionImpl.update(SessionImpl.java:695)
    at org.hibernate.internal.SessionImpl.update(SessionImpl.java:690)
    at cn.itheima.test.HibernateTest.test6(HibernateTest.java:127)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

    示例代码为:

    public class HibernateTest {
    
        // session的update操作
    @Test
    public void test6() {
    // 1.得到session
    Session session = HibernateUtils.openSession();
    session.beginTransaction(); // 得到id=1的Customer对象
    Customer cc = session.get(Customer.class, 1); // session的一级缓存中存在了一个OID为1的Customer对象 // 执行update来操作一个脱管对象
    Customer c = new Customer();
    c.setAddress("天门");
    c.setName("赵六");
    c.setId(1); // 注意:我这里是为了模拟,所以手动给其赋值ID,正常的实际开发中是不建议这么做的 session.update(c); // 当执行update时,会将c放入到session的一级缓存 // 2.事务提交,并关闭session
    session.getTransaction().commit();
    session.close();
    } }

    运行以上方法就会报上面的那个异常。 
    结论:session的一级缓存里面是不能出现两个相同OID的对象的

  2. 脱管对象的oid如果在数据表中不存在,会报异常如下:

    org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
    at org.hibernate.jdbc.Expectations$BasicExpectation.checkBatched(Expectations.java:67)
    at org.hibernate.jdbc.Expectations$BasicExpectation.verifyOutcome(Expectations.java:54)
    at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:46)
    at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3071)
    at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2950)
    at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3330)
    at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:145)
    at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:560)
    at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:434)
    at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:337)
    at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
    at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1282)
    at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:465)
    at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:2963)
    at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2339)
    at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:485)
    at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.beforeCompletionCallback(JdbcResourceLocalTransactionCoordinatorImpl.java:147)
    at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.access$100(JdbcResourceLocalTransactionCoordinatorImpl.java:38)
    at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:231)
    at org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:65)
    at cn.itheima.test.HibernateTest.test6(HibernateTest.java:130)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

    示例代码为:

    public class HibernateTest {
    
        // session的update操作
    @Test
    public void test6() {
    // 1.得到session
    Session session = HibernateUtils.openSession();
    session.beginTransaction(); // 执行update来操作一个脱管对象
    Customer c = new Customer();
    c.setAddress("天门");
    c.setName("赵六");
    c.setId(11); // 注意:我这里是为了模拟,所以手动给其赋值ID,正常的实际开发中是不建议这么做的 session.update(c); // 当执行update时,会将c放入到session的一级缓存 // 2.事务提交,并关闭session
    session.getTransaction().commit();
    session.close();
    } }

    运行以上方法就会报上面的那个异常。

所以,在实际操作中,除非一些特殊情况(但要保证OID一定要有),建议通过持久化对象来直接修改其操作。

saveOrUpdate

如果对象是一个瞬时对象,则执行save操作;如果对象是一个脱管对象(脱管对象在数据库中可能会存在),则执行update操作;如果对象是一个持久化对象,则不需要去处理它,而是直接返回。

delete

删除一个脱管对象时,首先要与session关联,然后再删除;如果是删除一个持久化对象,则直接删除。 
注意:如果执行delete操作,那么先删除一级缓存,再删除数据库表中的数据

最新文章

  1. Entity Framework 6 Recipes 2nd Edition(11-6)译 -&gt; 从一个”模型定义”函数里返回一个复杂类型
  2. JAVA之直接内存(DirectMemory)
  3. 笔记本中的archlinux调节亮度
  4. Html5离线缓存详细讲解
  5. codeforces 375D:Tree and Queries
  6. 【干货】Laravel --Validate (表单验证) 使用实例
  7. 2016年11月15日 星期二 --出埃及记 Exodus 20:6
  8. jquery如何判断div是否隐藏--useful
  9. 【LaTeX排版】LaTeX纸排版&amp;lt;两&amp;gt;
  10. fastjson升级版本遇到的问题
  11. 海量并发的无锁编程 (lock free programming)
  12. mysql8.0 定时创建分区表记录 每天定时创建下一天的分区表
  13. C# Winform多窗体&amp;&amp;构造函数传值
  14. 查询SQLSERVER执行过的SQL记录(测试通过)
  15. win10 64位,家庭版,C++,ini配置说明
  16. NOIP2016 D2-T3 愤怒的小鸟
  17. ubuntu 安装php 扩展和查看扩展包
  18. lambda----jdk8重头戏
  19. flash Timer 性能优化,每几秒间隔一次
  20. DateReader读取数据

热门文章

  1. nodejs 运行
  2. 闲聊ROOT权限——ROOT权限的前世今生
  3. HDU 4849 Wow! Such City!陕西邀请赛C(最短路)
  4. Raphael.js image 在ie8以下的兼容性问题
  5. 【C语言】不使用大小于号,求出两数最大值
  6. Codeforces Round #273 (Div. 2)C. Table Decorations 数学
  7. POJ 1663:Number Steps
  8. git 命令 —— checkout
  9. POJ2985 The k-th Largest Group treap
  10. 51. ExtJs4之Ext.util.JSON编码和解码JSON对象