spring cache 接口层缓存的演进过程

在spring 体系中,使用spring cache并结合redis来进行数据缓存是很常见的做法。不过,针对于具体的业务场景,可能会有不同的处理方法。

像以下的1个业务场景,即有不同的处理方式。

前端访问后端的指定请求路径(GET类请求), 针对特定的条件下(对应cache condition),希望这个结果能够被缓存.同时,支持当资源修改之后,让此缓存失效掉。

此场景的典型方案就是使用spring cache的 @Cacheable 注解 和 @CacheEvict 注解,并结合实际场景进行混合处理。

在这个实际的场景当中,经历了 service层缓存,Controller层缓存,和Filter层缓存三个阶段,最终达到业务的需求,并且在性能上更接近于实际的需要。
本文就里面碰到的一些实际问题以及解决方式进行了简单描述,从复杂的框架层修改到简单的拦截处理,在思考思路上进行一个分享。

前提
本文中使用的序列化为jackson,即使用jackson将对象序列化为 json 字符串,再getBytes为 字节数组.

继续阅读“spring cache 接口层缓存的演进过程”

从源码上分析hibernate的load和get之间的区别

一说到hibernate的get和load之间的区别,大多数网上的都会说出如下的区别:get不走缓存,load走缓存;或者get不会使用二级缓存之类,然而这些都是错误的。其实两者没有大多的区别,真正的区别在于二者获取对象的方式,以及如何使用对象上。本文从源码分析上分析两者的具体区别。本方使用的hibernate 版本为3.6.3。

获取对象的API,二者都使用统一的方式调用,如下所示:

来源于sessionImpl
		load的api:
                LoadEvent event = new LoadEvent(id, entityName, false, this);
		fireLoad( event, LoadEventListener.LOAD );
                
               get的api:
		LoadEvent event = new LoadEvent(id, entityName, false, this);
		fireLoad(event, LoadEventListener.GET);

可以看出,二者的api都一样,主要的不一样在于,触发事件的方式不一样。load时使用LoadEventListener.LOAD而get时使用LoadEventListener.GET。我们看看两者的具体不一样:

public static final LoadType GET = new LoadType("GET")
			.setAllowNulls(true)
			.setAllowProxyCreation(false)
			.setCheckDeleted(true)
			.setNakedEntityReturned(false);
	
	public static final LoadType LOAD = new LoadType("LOAD")
			.setAllowNulls(false)
			.setAllowProxyCreation(true)
			.setCheckDeleted(true)
			.setNakedEntityReturned(false);

主要的区别在于:在allowNulls上get允许而load不允许,allowProxyCreation上get不允许而load允许。具体这两者的区别在哪儿,我们进一步地从源码上进行分析。

继续阅读“从源码上分析hibernate的load和get之间的区别”