Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Core
    • Last commented by a User:
      true

      Description

      org.springframework.cache.interceptor.DefaultKeyGenerator is implemented by calculating the hashcode of all arguments. This is problematic in many cases:

      • methods with similar signature - foo(int, String), foo(int, List) - if the 2nd argument is null they will get mixed
      • methods with the same signature in different classes, using the same cache - they will get mixed
      • is there a collision resolution mechanism? If not, things will randomly fail. Rarely, but they will. Imagine that the arguments of two distinct methods (that use the same cache region) evaluate to the same hashcode (not unlikely) - they will override each other's values, and possibly a ClassCastException will occur on retrieval

      What is in the first place the reason to get the hashcodes? The underlying cache mechanism is a hashtable of some sort, so it will calculate the hash of the key anyway. But it will have a collision-resolution strategy, unlike the KeyGenerator.

      I suggest:

      • concatenating the string representations of primitives, and the hashcode of non-primitives.
      • adding the class name and method name to the key
      • optionally, where non-primitive values are used as keys, log a warning - this is usually wrong, as the hashcode will change even though the values inside the object are the same

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                pwebb Phil Webb
                Reporter:
                bozho Bozhidar Bozhanov
                Last updater:
                Phil Webb
              • Votes:
                9 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Days since last comment:
                  5 years, 24 weeks, 4 days ago