Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-10237

Cacheable key collision with DefaultKeyGenerator

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.2 GA
    • Fix Version/s: 4.0 M2
    • Component/s: Core
    • Labels:
      None

      Description

      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"

        Issue Links

          Activity

          Hide
          nurkiewicz Tomasz Nurkiewicz added a comment -

          Looks like a duplicate of SPR-9036 and SPR-9377.

          Show
          nurkiewicz Tomasz Nurkiewicz added a comment - Looks like a duplicate of SPR-9036 and SPR-9377 .
          Hide
          pwebb Phil Webb added a comment -

          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

          Show
          pwebb Phil Webb added a comment - 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

            People

            • Assignee:
              pwebb Phil Webb
              Reporter:
              ethlo Morten Haraldsen
              Last updater:
              Rob Winch
            • Votes:
              3 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                4 years, 18 weeks, 2 days ago