Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-11177

Need JPA related caching functionality to improve performance and support clustering

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 2.5
    • Component/s: JPA
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Similar issues:
      KULRICE-13149Address problems with JPA related caching
      KULRICE-1130improve performance of xml ingestion
      KULRICE-3857JPA - Research if second level caching is automatically turned on, if so determine if we need to disable it
      KULRICE-2452Implement cluster-aware caching on KNS System Parameters
      KULRICE-8714Bug related to caching used to improve role service performance.
      KULRICE-11178Need support for query customizers with JPA
      KULRICE-3225Implement cluster-safe cache on top of PreferencesService in KEW
      KULRICE-3689Improve performance of IdentityArchiveService interactions
      KULRICE-8956ComponentBase performFinalize Performance Improvement
      KULRICE-13088ObjectUtils deep copy related methods need to be ported over to JPA
    • Epic Link:
    • Application Requirement:
      KC
    • Sprint:
      2.4.0-m4 JPA Sprint 3, Core 2.5.0-m5 Sprint 2b, Core 2.5.0-m6 Sprint 1, Core 2.5.0-m6 Sprint 2
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes
    • Story Points:
      3

      Description

      Need JPA related caching to improve performance.

        Issue Links

          Activity

          Hide
          Jonathan Keller added a comment -

          Gayathri,

          If you want - testing of the JPA caching is now available (on trunk) by setting a new configuration property. I haven't completed the testing I want to do - so it's still off by default. There are issues, but I've been able to bypass them by making select objects (which have odd usage patterns) non-cacheable. (UserOptions & DocumentRouteHeaderValue)

          To turn it on, you can set this property:

          <param name="rice.krad.jpa.global.eclipselink.cache.shared.default">true</param>

          Show
          Jonathan Keller added a comment - Gayathri, If you want - testing of the JPA caching is now available (on trunk) by setting a new configuration property. I haven't completed the testing I want to do - so it's still off by default. There are issues, but I've been able to bypass them by making select objects (which have odd usage patterns) non-cacheable. (UserOptions & DocumentRouteHeaderValue) To turn it on, you can set this property: <param name="rice.krad.jpa.global.eclipselink.cache.shared.default">true</param>
          Hide
          Gayathri Athreya added a comment -

          Cool, thanks Jonathan. I will check it out.

          Show
          Gayathri Athreya added a comment - Cool, thanks Jonathan. I will check it out.
          Hide
          Jonathan Keller added a comment -

          Gayathri,

          At this point - I don't think it's going to work out to turn on the JPA L2 cache. We just do too many odd things in terms of data manipulation. Maybe if we had started with JPA. But not with the conversion from OJB. Things just don't behave as the framework expects and there does not seem to be a reasonable way to properly clear out all old references.

          I also have concerns about duplicate objects being returned from the L2 cache. We absolutely can not have that happen due to the way that the framework manipulates objects. (Loading to get a temp copy which it will modify but never save.) We would likely have quite a bit of data corruption since we don't have a good separation between persistent objects and data objects used during document/screen operation.

          Show
          Jonathan Keller added a comment - Gayathri, At this point - I don't think it's going to work out to turn on the JPA L2 cache. We just do too many odd things in terms of data manipulation. Maybe if we had started with JPA. But not with the conversion from OJB. Things just don't behave as the framework expects and there does not seem to be a reasonable way to properly clear out all old references. I also have concerns about duplicate objects being returned from the L2 cache. We absolutely can not have that happen due to the way that the framework manipulates objects. (Loading to get a temp copy which it will modify but never save.) We would likely have quite a bit of data corruption since we don't have a good separation between persistent objects and data objects used during document/screen operation.
          Hide
          Kristina Taylor (Inactive) added a comment -

          I've created KULRICE-13149 to address actually turning L2 cache on in Rice. It seems that this is still an experimental feature, and while it is available for people to try, we still have concerns about it. We should now close this issue.

          Show
          Kristina Taylor (Inactive) added a comment - I've created KULRICE-13149 to address actually turning L2 cache on in Rice. It seems that this is still an experimental feature, and while it is available for people to try, we still have concerns about it. We should now close this issue.
          Hide
          Jonathan Keller added a comment -

          Work for this issue is complete. The configuration option is now present in the application (defaulted to off.)

          There are, however, issues to resolve with regards to the returning of cached objects in situations the application framework does not expect. (Even when a DB-level refresh is requested.)

          If possible, these issues will be addressed in 2.6.

          Show
          Jonathan Keller added a comment - Work for this issue is complete. The configuration option is now present in the application (defaulted to off.) There are, however, issues to resolve with regards to the returning of cached objects in situations the application framework does not expect. (Even when a DB-level refresh is requested.) If possible, these issues will be addressed in 2.6.

            People

            • Assignee:
              Jonathan Keller
              Reporter:
              Gayathri Athreya
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Agile

                  Structure Helper Panel