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

Performance degradation for TransactionInterceptor

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Complete
    • Affects Version/s: 3.1.1
    • Fix Version/s: 3.1.3, 3.2 RC1
    • Component/s: Transaction
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      We tried to upgrade Spring framework from 2.5.5 to 3.1.1, during performance test we found that TransactionInterceptor will add some performance overhead because introduce of following method:
      org.springframework.transaction.interceptor.TransactionAspectSupport.methodIdentification(java.lang.reflect.Method,java.lang.Class)

      This new method will call Class.getDeclaredMethods() instead of using the method passed in directly.

      If there are multiple transaction pointcuts defined and invoked in one call, the performance will be affected badly.

      Can we do fallback support as 2.5.5 or add cache support for the method instead of call Class.getDeclaredMethods() each time?

        Issue Links

          Activity

          Hide
          gpatwa Gopal Patwa added a comment -

          it seems this feature was added as part of this jira

          https://jira.springsource.org/browse/SPR-7317

          Show
          gpatwa Gopal Patwa added a comment - it seems this feature was added as part of this jira https://jira.springsource.org/browse/SPR-7317
          Hide
          juergen.hoeller Juergen Hoeller added a comment -

          I've fixed this through direct use of targetClass.getName() + "." + method.getName(), always exposing the signature against the concrete target class. This is as efficient as the original code was in 2.5.5, with largely the same result as after the SPR-7317 change. And where it differs (e.g. in case of methods inherited from base classes), the result should actually be more meaningful than before (since the concrete class is what we dispatch to).

          Juergen

          Show
          juergen.hoeller Juergen Hoeller added a comment - I've fixed this through direct use of targetClass.getName() + "." + method.getName(), always exposing the signature against the concrete target class. This is as efficient as the original code was in 2.5.5, with largely the same result as after the SPR-7317 change. And where it differs (e.g. in case of methods inherited from base classes), the result should actually be more meaningful than before (since the concrete class is what we dispatch to). Juergen

            People

            • Assignee:
              juergen.hoeller Juergen Hoeller
              Reporter:
              newry Ray
              Last updater:
              Chris Beams
            • Votes:
              2 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                5 years, 9 weeks, 2 days ago