首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 软件管理 > 软件架构设计 >

Hibernate查询缓存的一个可靠性有关问题

2012-11-09 
Hibernate查询缓存的一个可靠性问题之前在对项目中Hibernate的缓存性能进行测试时发现的一个问题,不知大家

Hibernate查询缓存的一个可靠性问题
  之前在对项目中Hibernate的缓存性能进行测试时发现的一个问题,不知大家有没有遇到或者是解决办法。
    问题是:使用sql query且是多表关联查询,并启用查询缓存时,对关联表修改后,查询缓存未能更新,出现了不正确的查询结果集。

    测试场景:
    1. 用例:为简单起见,测试中使用了两表关联查询。查询指定角色 (roleCode) 的所有已授权限点 (Perm集合)
    2. 库表:
          权限点表(sys_perm )字段: permCode, permName, moduleCode,...
         角色授权表(sys_role_perm )字段: roleCode, permCode, createTime,...

   3. 关联查询
(其实仅判断所授权限点编码集合,用Hibernate 关联抓取,就可以解决,并且二级缓存也能很好的控制此问题;即使用 named sql query进行鉴权,也只需查 sys_role_perm表返回 permCode集合。这里返回 perm 集合, 这里主要是为测试关联查询时的cache query问题而举的一个例子)

<!-- 角色拥有的所有已授权限集合 --><sql-query name="system.roleperms">select  *  from sys_perm t join sys_role_perm o     on t.perm_code = o.perm_code     where o.role_code = :roleCode </sql-query></class>

   
    3. 预置数据:
         角色编码: STESTOR,
         权限点:permCode 组织新增: ORG_ADD
         在 sys_role_perm 表中为 STESTOR 授予 组织管理新增的权限:
        (STESTOR,ORG_ADD,2007-3-27 10:34:32)

    4. 测试代码:
     执行三次doQueryRolePerms 查询功能,在第二次执行完毕时,删除 (STESTOR,ORG_ADD) 这条授权,观察第三次查询是否重新去数据库取数。

for (int i = 0; i < 3; i++) {   System.out.println(" Execute No. " + i + " ********************");   List perms = (List)perm.doQueryRolePerms("STESTOR");    System.out.println("(" + i +")result size:"  + perms.size()  );   if(i % 2 == 1)     rolePerm.doRemoveByVO(rolePermVO1); //删除授权:STESTOR, ORG_ADD}

   
   5. 执行分析:
       第1,2次执行,由于有预置授权,因此 result size: 1;
       第3次执行查询,由于删除了唯一的授权,那么 result size: 0。

    6. 实际结果:
       
 Execute No. 0 ********************2008-10-06 17:26:26,406 [DEBUG](AbstractBatcher.java,324) - select  this.PERMCODE as  PERM1_0_,  this.MODULECODE as  MODULE2_15_0_,  this.PERMTYPECODE as  PERM3_15_0_,  this.PERMNAME as  PERM4_15_0_,  this.PERMDESC as  PERM5_15_0_,  this.PORTNO as  PORT6_15_0_ from (select  t.perm_code as permCode,        t.module_code as moduleCode,        t.perm_name as permName,        t.perm_desc as permDesc,        t.port_no as portNo,        t.perm_type_code as permTypeCode   from sys_perm t join sys_role_perm o     on t.perm_code = o.perm_code     where o.role_code = ? ) this  (No.0)result size:1 Execute No. 1 ********************(No.1)result size:12008-10-06 17:26:26,484 [DEBUG](AbstractBatcher.java,324) - delete from SYS_ROLE_PERM where PERM_CODE=? and ROLE_CODE=? Execute No. 2 ********************(No.2)result size:1Time: 0.422OK (1 test)       


      从结果可以看出,第1次,执行了查询;
       第2次没有执行查询,说明 query cache,二级cache都起了作用。
       但第3次查询,没有重新执行sql,仍然返回的是第二缓存的结果。
       因此可以判定, 第3次查出的是旧数据。

     7. 分析及结论:
      Hibernate query cache 在关联表的数据删除时,没能通知查询缓存及时失效或更新, 以便获取最新数据。

     8. 解决办法
     暂时还没找到Hibernate自身的解决办法, 为避免此问题,可以关闭查询缓存。 看大家有没有遇到过此问题,分享下你们的经验。

     如果hibernate真的没有解决这个问题,我能想到的一个思路就是,在 named query执行时,分析出查询的关联表,并在关联表进行 create,update,delete时及时通知该 named query的缓存失效。
     关联查询,特别是多表关联,且操作复杂时,要精细的进行缓存通知比较困难(例如:修改了 Admin 角色的授权,就对上例的查询没有影响,而修改了 STESTOR 角色的授权才需要通知cache更新,但这判断起来有一定难度),可以做一个笼统的逻辑,即 create,update,delete 关联表后,对 named query的cache都要通知它清除,以便重新查询获取最新数据。

      query cache的利用率,即命中率取决于具体业务的增删改操作的频率,这个测试暂不考虑此因素 query cache的价值问题。


   经过一天的努力,终于解决此问题, 并附源代码和fix包: 解决Hibernate SQL Query Cache的一个可靠性问题(附源码) 1 楼 QuakeWang 2008-10-06   注意到你这里使用的是sql-query,可能hibernate的cache清除机制对sql-query没有处理,我在以往的项目中使用query cache都是hsql,实践证明是很可靠的,你可以将sql-query改成hsql试试看。

另外推荐这篇分析hibernate query cache原理的文章:
http://www.iteye.com/topic/10537 2 楼 raymond2006k 2008-10-07   回楼上,hql的缓存可靠性虽然没实测,但根据hibernate 处理hql的内在机制,和你们的经验,相应肯定是没问题的, 因为hibernate很容易在解析 hql 时判断出关联表。

主要是我们项目处于项目特点的考虑,主要使用的是 named sql query。
在浏览hibernate源码时,某一天突然对 hibernate 能否很好的处理 sql  方式下的query cache可靠性产生了一点好奇, 然后就进行了测试。 本来期待它应该很好的处理了这个问题,但测试结果也出乎我的意料。  估计Gavin King 老人家漏了这一环,呵呵。

firebody 那篇帖子很受用,呵呵,多谢了。 我也的再详细读读源码了,看能否找出敏捷的解决办法;或者看看新版本有没有解决此问题。 3 楼 QuakeWang 2008-10-07   raymond2006k 写道
主要是我们项目处于项目特点的考虑,主要使用的是 named sql query。

很好奇你的项目有什么特殊地方,需要大量使用native sql query?
hibernate提供native sql query目的是为了在极少场景下能够使用一些数据库的特性,比如说oracle的connect查询。从你前面的例子看,用普通的hsql比native sql要简单许多,也看不出来有地方需要用到数据库的特殊sql语句。
4 楼 raymond2006k 2008-10-07   主要是一些复杂的查询,比如多表关联(3表,5表等), 无VO对应结果集查询等。
这样选型有我们的考虑, 一两句话也说不完,我另一片帖子比较详细的说了为什么用 sql query的问题。

这个不是重点啦,项目都完工了。 高手,你就当发现了 hibernate 使用时的问题,正在找解决办法,:)  。

下午抽空用 hibernate3.3.0 GA , 3.3.1 GA 测试了一下,依然有此问题。
5 楼 raymond2006k 2008-10-07   不过时间没白费, 走了一下源码,大致找到了问题所在,  SQLQueryReturnProcessor在分析 query时,用于判断缓存失效的  querySpaces[]只分析出了返回结果对应的表,例如例子中的权限点表:sys_perm,  而sql中的关联表没有分析出来,并放到 querySpaces[] 中。

明天争取能通过修改源码解决此问题。:)
落班,收工。 6 楼 raymond2006k 2008-10-08   经过一天的努力,终于解决此问题。 具体分析和修正方法见下篇 blog 并附源代码和fix包: 解决Hibernate SQL Query Cache的一个可靠性问题(附源码) 7 楼 QuakeWang 2008-10-08   不错,可以提交bug fix给hibernate团队

热点排行