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

Caching Abstraction ignores method name?

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Critical
    • Resolution: Won't Fix
    • Affects Version/s: 3.1 GA
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None
    • Last commented by a User:
      true

      Description

      When I read the reference documentation I thought the caching abstraction is on method level, but it seems it is only on the parameter value of the methods.

      If I have several methods with the same parameter type it get always the same return value:

      @Component
      public class CacheTestImpl implements CacheTest {
      @Cacheable("databaseCache")
      public Long test1()

      { return 1L; }

      @Cacheable("databaseCache")
      public Long test2()

      { return 2L; }

      @Cacheable("databaseCache")
      public Long test3()

      { return 3L; }

      @Cacheable("databaseCache")
      public String test4()

      { return "4"; }

      }

      Calling now:

      System.out.println(test.test1());
      System.out.println(test.test2());
      System.out.println(test.test3());
      System.out.println(test.test4());

      results in:

      1
      1
      1
      ClassCastException: java.lang.Long cannot be cast to java.lang.String

      Is this the desired behaviour? I would expect:

      1
      2
      3
      4

      If I use different caches it works.

      I can't access github from my place (firewall) so I have added a tar with a small maven project showing this problem.

      Greets Alex

      1. cacheproblem.tar
        70 kB
        Alexander Derenbach
      2. MethodAwareCacheKeyGenerator.java
        0.4 kB
        Mukarram Baig

        Issue Links

          Activity

          Hide
          derenbacha Alexander Derenbach added a comment -

          Hello Ned,

          I am glad that I am not the only one who miss understood it. (or expected something else).
          My solution for my problem is now this (as mentioned above)

          @Cacheable(value="databaseCache", key="

          {#root.methodName,#test}

          ")
          public Long test(Long test)

          { return test; }

          this works fine.

          But I agree with you that at least the documentation could perhaps mention the behavior a bit better, since they are talking about "method caching" which leads me to my expecting of the cache.

          Greets Alex

          Show
          derenbacha Alexander Derenbach added a comment - Hello Ned, I am glad that I am not the only one who miss understood it. (or expected something else). My solution for my problem is now this (as mentioned above) @Cacheable(value="databaseCache", key=" {#root.methodName,#test} ") public Long test(Long test) { return test; } this works fine. But I agree with you that at least the documentation could perhaps mention the behavior a bit better, since they are talking about "method caching" which leads me to my expecting of the cache. Greets Alex
          Hide
          kilokahn Mukarram Baig added a comment -

          Hello Costin and gang - Thanks for the great work thus far! I too tend to agree with Ned that the behavior is slightly counter-intuitive. I was trying to cache calls to a third party JAR via the cache:advice route and Ned's suggestion to have a MethodAwareCacheKeyGenerator helped me out. Can we provide such a key generator from Spring rather than having each user hand-roll their own? I am attaching an implementation that I am using.

          Show
          kilokahn Mukarram Baig added a comment - Hello Costin and gang - Thanks for the great work thus far! I too tend to agree with Ned that the behavior is slightly counter-intuitive. I was trying to cache calls to a third party JAR via the cache:advice route and Ned's suggestion to have a MethodAwareCacheKeyGenerator helped me out. Can we provide such a key generator from Spring rather than having each user hand-roll their own? I am attaching an implementation that I am using.
          Hide
          kilokahn Mukarram Baig added a comment -

          Updated definition

          Show
          kilokahn Mukarram Baig added a comment - Updated definition
          Hide
          wajda Alex Wajda added a comment - - edited

          Please do not close it as "Invalid" because it is pretty much valid.
          The current behaviour is too counter intuitive.
          The following conclusion is at least illogical.

          ...for the most part, different methods can share the same result

          The different methods are aimed to have different semantics and event though the input can be the same the result will most likely to be different. Otherwise why would 2 methods with identical semantics co-exist?

          I would vote for making the (methodName,arg1,arg2,...,argN) to be the default key. So that even the key spaces for overloaded methods would not overlap. To me that is the most sensible default.

          Show
          wajda Alex Wajda added a comment - - edited Please do not close it as "Invalid" because it is pretty much valid. The current behaviour is too counter intuitive. The following conclusion is at least illogical. ...for the most part, different methods can share the same result The different methods are aimed to have different semantics and event though the input can be the same the result will most likely to be different. Otherwise why would 2 methods with identical semantics co-exist? I would vote for making the (methodName,arg1,arg2,...,argN) to be the default key. So that even the key spaces for overloaded methods would not overlap. To me that is the most sensible default.
          Hide
          chrismarx chris marx added a comment -

          I agree, I think most people would assume that the method signature would be part of the cache key generation-

          Show
          chrismarx chris marx added a comment - I agree, I think most people would assume that the method signature would be part of the cache key generation-

            People

            • Assignee:
              pwebb Phil Webb
              Reporter:
              derenbacha Alexander Derenbach
              Last updater:
              chris marx
            • Votes:
              5 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                3 years, 7 weeks, 3 days ago