Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cacheable key collision with DefaultKeyGenerator [SPR-10237] #14870

Closed
spring-issuemaster opened this issue Jan 29, 2013 · 2 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Jan 29, 2013

Morten Haraldsen opened SPR-10237 and commented

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" :-)


Affects: 3.2 GA

Reference URL: http://blog.ethlo.com/2013/01/30/spring-defaultkeygenerator-gotcha

Issue Links:

  • #15316 Spring cache defaults to hashcode based cache key for multiple arguments ("is duplicated by")
  • #13675 Improve DefaultKeyGenerator ("is duplicated by")
  • #14013 org.springframework.cache.interceptor.DefaultKeyGenerator has too weak hashing functionality ("is duplicated by")
  • #13675 Improve DefaultKeyGenerator
  • #14013 org.springframework.cache.interceptor.DefaultKeyGenerator has too weak hashing functionality

Referenced from: commits f1a18d2

3 votes, 8 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 1, 2013

Tomasz Nurkiewicz commented

Looks like a duplicate of #13675 and #14013.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 21, 2013

Phil Webb commented

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 #13675). 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.