|
精华帖 (1) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-05-14
上代码，看下你是如何实现的~
|
| 返回顶楼 | |
|
发表时间：2012-05-14
我说的意思是，在一对多这种情况下。条件是复杂的，需要用户自己来掂量需不需要维护这个list cache 还是选择直接干掉这个list cache
|
| 返回顶楼 | |
|
发表时间：2012-05-14
最后修改：2012-05-14
jinnianshilongnian 写道 onecan 写道 jinnianshilongnian 写道 1、Entity更新时从RelationShop找到对应的List并更新
这个不需要吧 因为你的List存的只是ID啊 2、RelationShop cache 以Entity ID 作为key, 记录引用到这个Entity的List的所在的cache名称和key,用于当Entity更新时找到他所影响的List一起做更新操作 建议上一个时间戳缓存，类似于Hibernate，我觉得要比RelationShop好。 3、当Entity Create Delete时应该直接删除List/修改时间戳吧？ 4、你们现在 List如何保存呢？ 如何得到Entity类型？ 如果List为空呢？ 几点疑问和见解 1。刚才提到了List cache有2种方案，1.放ID List, 2. 放整个List。比如这个List下的某个Entity更新或者删除了，那这个List就要作废了，需要重新从数据库拿记录。这2种方案在其关联的Entity改变之后，都要干掉List Cache 2。RelationShop cache 的数据结构是这样的， Entity ID:{[cachename1, key1],[cachename2, key2]...}, 不知道你说的时间戳是否ehcache的create time? 3. Entity Cache 更新时通过RelationShop cache找到他所影响的List Cache 并删除，跟着删除对应的RelationShop cache 4. Cache name就是一个Entity name, 每个Entity实现一个BadeEntity的接口，里面有一个getId()的方法需要实现，对Cache而言，我不需要知道Entity的类型，只要知道他的Id作为Key就好，value的类型是Object. List为空也是一种结果缓存下来的，只是他不受任何Entity的影响。 2。RelationShop cache 的数据结构是这样的， Entity ID:{[cachename1, key1],[cachename2, key2]...}, 不知道你说的时间戳是否ehcache的create time? 不是create time 是修改的时间。 hibernate也是采用这种时间戳方式 比如你有个Entity 有一个 如 s属性 原来为1 后来修改成 2 但你有一个查询 条件为s>1 这样你的List可能有几个失效的。 这个你的场景会遇到吗？ 当这个Entity update的时候，会就触发一系列的动作。 1. delete entity cache by id, 2. delete List cache keep in RelationShop by Entity id 3.delete RelationShop cache by Entity id 所以是整个List removed,而不是记录时间戳再update部分数据，而且不是每个Entity都有时间戳的。 |
| 返回顶楼 | |
|
发表时间：2012-05-14
onecan 写道 jinnianshilongnian 写道 onecan 写道 jinnianshilongnian 写道 1、Entity更新时从RelationShop找到对应的List并更新
这个不需要吧 因为你的List存的只是ID啊 2、RelationShop cache 以Entity ID 作为key, 记录引用到这个Entity的List的所在的cache名称和key,用于当Entity更新时找到他所影响的List一起做更新操作 建议上一个时间戳缓存，类似于Hibernate，我觉得要比RelationShop好。 3、当Entity Create Delete时应该直接删除List/修改时间戳吧？ 4、你们现在 List如何保存呢？ 如何得到Entity类型？ 如果List为空呢？ 几点疑问和见解 1。刚才提到了List cache有2种方案，1.放ID List, 2. 放整个List。比如这个List下的某个Entity更新或者删除了，那这个List就要作废了，需要重新从数据库拿记录。这2种方案在其关联的Entity改变之后，都要干掉List Cache 2。RelationShop cache 的数据结构是这样的， Entity ID:{[cachename1, key1],[cachename2, key2]...}, 不知道你说的时间戳是否ehcache的create time? 3. Entity Cache 更新时通过RelationShop cache找到他所影响的List Cache 并删除，跟着删除对应的RelationShop cache 4. Cache name就是一个Entity name, 每个Entity实现一个BadeEntity的接口，里面有一个getId()的方法需要实现，对Cache而言，我不需要知道Entity的类型，只要知道他的Id作为Key就好，value的类型是Object. List为空也是一种结果缓存下来的，只是他不受任何Entity的影响。 2。RelationShop cache 的数据结构是这样的， Entity ID:{[cachename1, key1],[cachename2, key2]...}, 不知道你说的时间戳是否ehcache的create time? 不是create time 是修改的时间。 hibernate也是采用这种时间戳方式 比如你有个Entity 有一个 如 s属性 原来为1 后来修改成 2 但你有一个查询 条件为s>1 这样你的List可能有几个失效的。 这个你的场景会遇到吗？ 当这个Entity update的时候，会就触发一系列的动作。 1. delete entity cache by id, 2. delete List cache keep in RelationShop by Entity id 3.delete RelationShop cache by Entity id 那你的映射 特别多啊 如果1w条Entity 则有至少1w个RelationShop啊 |
| 返回顶楼 | |
|
发表时间：2012-05-14
大哥，都晚上了怎么还没上传。。。
|
| 返回顶楼 | |
|
发表时间：2012-05-15
代码已经上传，可以通过配置LegendCacheManager中的supportQueryCache，removeAllEntries来实现不同的需要
supportQueryCache，removeAllEntries description false false 不启用二级缓存，也不及时更新List cache,适合数据改动少，对实时性要求不高的情况，比较高的命中率 false true 不启用二级缓存，及时更新List cache,适合数据改动少，对实时性要求高的情况，List容易失效，命中率低 true ignore 启用二级缓存，及时更新List cache, 对实时性要求高的情况，命中率高，牺牲一定的内存 问题： 1.现在的key不一定合适memcached 2.多线程问题，对于缓存的更新需要把get and put 做成原子操作，要不RelationShop cache中可能会漏掉部分数据，导致不能及时更新List cache |
| 返回顶楼 | |
|
发表时间：2012-05-15
我一直对MethodInterceptor感到不解，难道这个方法会拦截所有的方法？
实际上我们只需要拦截被annotation注解的方法额 |
| 返回顶楼 | |
|
发表时间：2012-05-17
这个要重新温习一下Aop的概念了，要中了pointcut才会拦截并进入拦截器，Spring cache 通过CacheInterceptor来实现拦截的，CacheInterceptor实现了MethodInterceptor接口，只会拦截配置了cache annotation的方法而已。pointcut的定义方式比较多的，一般是采用动态代理或者aspectj。可以参考其他文章。
|
| 返回顶楼 | |
|
发表时间：2012-05-17
最后修改：2012-05-18
如果有个list(9,8,7,6,5) 当我新添加一条记录10, 这个时候如果同样的查询条件查出的应该是list(10,9,8,7,6)[类似于分页倒序记录的添加] 而此时RelationShop缓存中还没有 对应于list(10,9,8,7,6) 的关系. 这个时候怎么通知list(9,8,7,6,5)更新呢?
|
| 返回顶楼 | |
|
发表时间：2012-05-18
最后修改：2012-05-18
就如楼上所提到的, 根据某种条件查出来的list, 再查一次结果就会不一样了.
在hibernate中,主要是保存查询出来的object, 查出来的list,会根据list获取对象,有了缓存就从缓存中获取数据, 就节省获取对象的时间. 对于list的缓存, hibernate会记录一下查询用到的依赖表,一旦依赖表发生变动,无论是否影响到这个list的结果, 一律删除(hibernate也无法知道是否会影响查询结果) 对于自己做的缓存, 除非对数据的精确度要求不高, 不建议对list也做缓存; |
| 返回顶楼 | |
