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
          Jessica Coltrin (Inactive) added a comment -

          need more info here on what's being requested. Gayathri & Terry have asked Travis to provide that so I'm assigning this to him.

          Show
          Jessica Coltrin (Inactive) added a comment - need more info here on what's being requested. Gayathri & Terry have asked Travis to provide that so I'm assigning this to him.
          Hide
          Travis Schneeberger added a comment -

          Rice currently provides a distributed caching solution through the spring cache abstraction & ehcache. This caching implementation works across a cluster. This solution is meant as a service level caching solution.

          KC has some very nasty performance problems which in many cases originate from the persistence layer. KC currently does not use any service level caching. There are a few reasons why this has not happened. In order to implement a service level caching solution, KC needs to have a well defined service/data access tier which it currently does not have. KC has services and Daos but they aren't well defined or even consistently used (it is common for KC to call BOService inline for example). So in order to implement service level caching, KC will need to go through quite a bit of analysis, refactoring, configuration, and annotations (ideally even modularity). KC is currently not in a position to be able to do that given all the other initiatives (KRAD, JPA, Integration Testing).

          JPA has the concept of an Entity cache. Out of the box this cache is not safe for use in a cluster so rice recommends disabling it. KC would like to use this cache as it would provide performance benefits of JPA caching without the required analysis and refactoring, configuration and annotations. In other words, KC would not need to change any code to start seeing advantages from cached data. Without this, the @Cacheable & @Cache annotations do not function in a rice enabled JPA application under the required configuration for a clustered environment.

          In order for this to work, the rice team would need to hook the JPA caching backend into spring cache, ehcache, and the distributed caching infrastructure.

          Currently, the benefits from JPA caching are assumed with no concrete numbers to back up this assumption. We cannot create these metrics until we having KC running under JPA. This is ongoing.

          Show
          Travis Schneeberger added a comment - Rice currently provides a distributed caching solution through the spring cache abstraction & ehcache. This caching implementation works across a cluster. This solution is meant as a service level caching solution. KC has some very nasty performance problems which in many cases originate from the persistence layer. KC currently does not use any service level caching. There are a few reasons why this has not happened. In order to implement a service level caching solution, KC needs to have a well defined service/data access tier which it currently does not have. KC has services and Daos but they aren't well defined or even consistently used (it is common for KC to call BOService inline for example). So in order to implement service level caching, KC will need to go through quite a bit of analysis, refactoring, configuration, and annotations (ideally even modularity). KC is currently not in a position to be able to do that given all the other initiatives (KRAD, JPA, Integration Testing). JPA has the concept of an Entity cache. Out of the box this cache is not safe for use in a cluster so rice recommends disabling it. KC would like to use this cache as it would provide performance benefits of JPA caching without the required analysis and refactoring, configuration and annotations. In other words, KC would not need to change any code to start seeing advantages from cached data. Without this, the @Cacheable & @Cache annotations do not function in a rice enabled JPA application under the required configuration for a clustered environment. In order for this to work, the rice team would need to hook the JPA caching backend into spring cache, ehcache, and the distributed caching infrastructure. Currently, the benefits from JPA caching are assumed with no concrete numbers to back up this assumption. We cannot create these metrics until we having KC running under JPA. This is ongoing.
          Hide
          Jonathan Keller added a comment -

          Actually - this would appear to be a problem for any Rice application which wanted to cluster. It seems that EL has the shared cache turned on by default. So, we've been running with it except for 4 objects (plus one in the sample app) which have the JPA cache turned off via annotation.

          Show
          Jonathan Keller added a comment - Actually - this would appear to be a problem for any Rice application which wanted to cluster. It seems that EL has the shared cache turned on by default. So, we've been running with it except for 4 objects (plus one in the sample app) which have the JPA cache turned off via annotation.
          Hide
          Jonathan Keller added a comment -

          Also - any implementation which attaches to ehCache (or even turning on the clustering abilities of EclipseLink) will require more EL-specific implementation code, as there is no common implementation aside from the @Cache annotation provided by the JPA 2.0 spec.

          Show
          Jonathan Keller added a comment - Also - any implementation which attaches to ehCache (or even turning on the clustering abilities of EclipseLink) will require more EL-specific implementation code, as there is no common implementation aside from the @Cache annotation provided by the JPA 2.0 spec.
          Hide
          Jonathan Keller added a comment -

          So - is KC disabling the JPA cache? From what I can see, it should be turned on. (Unless we are continuously flushing it...in which case distributing the cache won't help, since the flush will then be distributed...)

          Show
          Jonathan Keller added a comment - So - is KC disabling the JPA cache? From what I can see, it should be turned on. (Unless we are continuously flushing it...in which case distributing the cache won't help, since the flush will then be distributed...)
          Hide
          Jonathan Keller added a comment -

          Never mind on that one...I just found the code which is disabling the shared cache.

          org.kuali.rice.krad.data.jpa.eclipselink.KradEclipseLinkEntityManagerFactoryBean.loadCustomJpaDefaults(Map<String, String>)

          jpaProperties.put(PersistenceUnitProperties.CACHE_SHARED_DEFAULT, "false");

          Now - given that we have done all our testing with the cache turned off - how much would you be willing to bet that the application will break horribly if I turn it on...

          There may be a lot of changes for KC to make to add the standard transactional annotations, but I have to wonder if we will not be creating even more problems (and work) for Rice and other client projects if we turn that cache on.

          Show
          Jonathan Keller added a comment - Never mind on that one...I just found the code which is disabling the shared cache. org.kuali.rice.krad.data.jpa.eclipselink.KradEclipseLinkEntityManagerFactoryBean.loadCustomJpaDefaults(Map<String, String>) jpaProperties.put(PersistenceUnitProperties.CACHE_SHARED_DEFAULT, "false"); Now - given that we have done all our testing with the cache turned off - how much would you be willing to bet that the application will break horribly if I turn it on... There may be a lot of changes for KC to make to add the standard transactional annotations, but I have to wonder if we will not be creating even more problems (and work) for Rice and other client projects if we turn that cache on.
          Hide
          Gayathri Athreya added a comment -

          We agree with the testing work needed but since this is new functionality, we'd rather get this in Rice 2.5 as long as there is a way to turn it off. We can fix bugs as and when they arise.

          Show
          Gayathri Athreya added a comment - We agree with the testing work needed but since this is new functionality, we'd rather get this in Rice 2.5 as long as there is a way to turn it off. We can fix bugs as and when they arise.
          Hide
          Jonathan Keller added a comment -

          I've been testing this morning - at some parts of the KEW infrastructure do not like it turned on. I'm going to continue looking into this tomorrow, but the use of the cache is definitely causing problem behaviors.

          Show
          Jonathan Keller added a comment - I've been testing this morning - at some parts of the KEW infrastructure do not like it turned on. I'm going to continue looking into this tomorrow, but the use of the cache is definitely causing problem behaviors.
          Hide
          Jonathan Keller added a comment -

          I'm going to move the hard-coding into a configuration property. That will allow you to turn it on. (I'd like to have it on for the entire system, but we'll see what testing reveals.)

          It should also be possible to turn it on on a module by module (PU-by-PU) basis.

          Show
          Jonathan Keller added a comment - I'm going to move the hard-coding into a configuration property. That will allow you to turn it on. (I'd like to have it on for the entire system, but we'll see what testing reveals.) It should also be possible to turn it on on a module by module (PU-by-PU) basis.
          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