关键字:查询,事务,粒度

to  NicholasBugs
     


-----------------------------------------------------------------------
其实很多场景我们都可以看到在view层使用cache的例子,比如ehcache和oscache能够缓存页面,我想我们可以把这种场景叫做 open cache in view, 但是这个东西也不是适合于所有的场景,因为缓存这种东西用起来并不是千篇一律的,得根据项目得实际情况而定.


大多数情况下我们会在我们得业务里用到缓存,如果是大并发情况,就要考虑一下能否缩小事务得范围了

有没有考虑过这样的一种办法：

我们禁用掉Hibernate的二级缓存。
然后我们通过spring的aop，对某些方法的返回结果直接加入缓存，
容过spring的aop，在某些方法执行之后更新缓存里面的结果。

也就是说，这里的缓存是我们自己做的而不是hibernate做的。
原因是因为，我们使用hibernate的时候只使用hql语句，能用hql的就用hql。别的坚决不用。

就我碰见的情况下，我认为多数时候是用不到Hibernate的二级缓存的。所以绝大多数的使用Hibernate做ORM的Entity，我都不开启二级缓存。仅仅对一些只读表，或者修改频率非常非常低的表使用二级缓存。而且针对这些表的读取，我会非常小心，尽量在系统启动的时候就用一次list操作把表中的大部分记录装入二级缓存，接下来就可以随意使用了，而且基本上会全部命中。

Spring的AOP应用缓存的场景非常常见，不过一般Service层会包含非常复杂的逻辑，所以这样的缓存可能也只能使用于业务逻辑相对简单的场景。因为对于复杂的逻辑来说，我们往往需要根据逻辑来判断，业务逻辑到达了某个步骤，才从缓存取数据，而不是简单的先查缓存，查不到再调业务逻辑方法。所以Spring的AOP在缓存的应用上会非常有限。

缓存的使用，越是在层次高的地方使用，使用的效果和程序的效率会越高。但是越是层次高的地方，也越无法包含复杂的逻辑判断，所以是一个权衡。

downpour说得没错:

缓存在不同得层次上使用的效果确实是不一样的,不过一般来说它们有一下规律:

越靠近用户(浏览器或者其他客户端)的地方,性能效果越明显,但是局限性越高
越远离用户(浏览器或者其他客户端)的地方,局限性越小(可以加入更多的逻辑),但是性能显然没有前者高

所以程序员要做的就是在缓存和用户的距离之间做权衡,做权衡的时候要考虑的因素很多,本文描述的也是要考虑的一个方面

而对于基于aop的methodCache,是我们最经常用的缓存方法之一,该方法最早是04年有人提出来的,那时候spring才正式立项不久,到现在4年过去了,methodcache也成为了最常用的技术之一,

不过即使使用methodcache,我们同样要考虑是否关联到事务的问题

呵呵，我们项目都不用事务

apache ab工具
apache 安装目录bin下的

前几天看到过AOP缓存，也觉得应用起来比较困难。

是这样的，做缓存的时候是缓存DAO层的内容而不是service层的内容。

我现在的问题是把hibernate的二级缓存禁用掉，使用spring的aop来做缓存，会不会带来什么副作用？

个人感觉稍微复杂一点就不行。
比如如果一个表，只有一块代码维护，那么可以用aop来作缓存。如果多个地方维护，或者是多表连查，别的表的数据变了，缓存就失效了。

如果你使用spring，最好的方法还是不要使用的声明式事务了(或只对更新数据库的方法声明式事务），最好使用TransactionTemplate对象手工完成，例如,以下针对hibernate的应用：

Object o = cacheClient.get(key);
if(o==null){
  readOnlyTransactionTemplate.execute(
  new transactionCallback(TransactionStatus transactionStatus){
       o = dao.get(key);
  }
}
return o;

代码把cache代码和事务代码分隔到不同的方法,然后再做一个外壳方法,这种只使用于复杂的业务方法。如果只是一个简单的读取,我觉的还是上面的代码会好一些