Fetch与Cache

通过测试我发现，通过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