Fetch与Cache
Fetch与Cache
猪刚烈 发表于3年前
Fetch与Cache
  • 发表于 3年前
  • 阅读 3
  • 收藏 0
  • 点赞 0
  • 评论 0

通过测试我发现,通过Fetch得去的对象是不会放入二级缓存的!(但它极有可能被放入查询缓存!这一点明天研究一下。)凡是Fetch的对象都会通过生成SQL从数据库重建。这一点和 http://blog.csdn.net/bluishglc/archive/2010/05/16/5597043.aspx 中所提到的情况暗合!为什么说“暗合”呢?目前来看,我们可以认为:在Hibernate中Fetch出来的对象似乎总是“二等公民”,它们只被它们的宿主对象所知,从全局的角度(Session)是看不到这些对象的。(是这样的么?明天做一下测试。搞明白session和session的缓存一回事么?)这就是为什么这些被Fetch的对象明明已经加载到了内存中,但是在二级缓存中却找不它们。反面的印证就是从宿主对象导航到Fetch出来的从属对象时并不会导致SQL产生,但如果从属对象不是通过Fetch加载的,即使它们之前已被加载出来,在导航到这些对象时还是生成SQL的。(此时正是使用二级缓存的好时机,如果使用的话,就不会生成SQL了!)这就是Fetch和二级缓存之间微妙的关系。

 

记住非常重要的一点:

通过load,get和对象间导航得到的对象都是二级缓存的目标!通过查询得到的对象是不会进行二级缓存的,而是进入查询缓存!


做一个测试:先通过HQL查询一个对象。然后使用load得到这个对象,在使用二级缓存的情况下,看一看是什么结果!

 

查询中产生的对象会进入Session上下文。此时如果通过session来load这些对象会直接命中,不会生成SQL。

但是查询本身不会试图从上下文中查找对象。而是必定生成SQL。

 

例子:

        //The hql is: from Thread
        threadRepository.loadAll();
        logger.debug("ALL");
        threadRepository.load(1L);
        logger.debug("1 L");
        threadRepository.load(2L);
        logger.debug("2 L");

结果:

DEBUG - SQLStatementLogger.logStatement(111) |
    /* criteria query */ select
        this_.id as id5_0_,
        this_.creationTime as creation2_5_0_,
        this_.forumId as forumId5_0_,
        this_.modifiedTime as modified3_5_0_,
        this_1_.subjectId as subjectId6_0_
    from
        Thread this_
    left outer join
        Thread_Subject this_1_
            on this_.id=this_1_.threadId
DEBUG - ForumTest.testGetForumById(37) | ALL
DEBUG - ForumTest.testGetForumById(39) | 1 L
DEBUG - ForumTest.testGetForumById(41) | 2 L

 

 

 


共有 人打赏支持
粉丝 21
博文 708
码字总数 110
作品 1
×
猪刚烈
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: