Cacheable key collision with DefaultKeyGenerator
2015-01-07 01:06 Rollen Holt 阅读(1031) 评论(0) 编辑 收藏 举报The default is to use the hashcode of each parameter and create another (32-bit) hash code. Obviously this can easily generate collisions. This should be clearly documented as it feels like a pretty serious issue, if not a bug. We have come to expect that Spring defaults are "safe"
https://jira.spring.io/browse/SPR-10237
Spring 4.0 will now use the SimpleKeyGenerator class to generate cache keys if no specific KeyGenerator is configured. The DefaultKeyGenerator remains available for applications that do not wish to migrate.
I have stopped sort of including the target object or method name inside the key (as suggested in SPR-9036). The primary reason for this is that the same key needs to be generated for @Cacheable, @CachePut and @CacheEvict annotated method, which will most likely be on different methods and potentially different beans.
For any method with a single non-null parameter, the result of SimpleKeyGenerator is identical to DefaultKeyGenerator. In other cases it is possible that the SimpleKey type might not be compatible with all Cache implementations. Given the number of times that this bug has been raised I think this restriction is acceptable, however, since this is a potentially breaking change I do not intend to back-port to 3.2.x
- [Spring DefaultKeyGenerator gotcha](Spring DefaultKeyGenerator gotcha)
==============================================================================
本博客已经废弃,不在维护。新博客地址:http://wenchao.ren
我喜欢程序员,他们单纯、固执、容易体会到成就感;面对压力,能够挑灯夜战不眠不休;面对困难,能够迎难而上挑战自我。他
们也会感到困惑与傍徨,但每个程序员的心中都有一个比尔盖茨或是乔布斯的梦想“用智慧开创属于自己的事业”。我想说的是,其
实我是一个程序员
==============================================================================