[KULRICE-11177] Need JPA related caching functionality to improve performance and support clustering Created: 04/Nov/13  Updated: 24/Sep/14  Resolved: 25/Aug/14

Status: Closed
Project: Kuali Rice Development
Component/s: JPA
Affects Version/s: None
Fix Version/s: 2.5
Security Level: Public (Public: Anyone can view)

Type: Improvement Priority: Critical
Reporter: Gayathri Athreya Assignee: Jonathan Keller
Resolution: Complete Votes: 0
Labels: Architecture
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
cloned to KULRICE-13149 Address problems with JPA related cac... Open
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: JPA Support
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.



 Comments   
Comment by Jessica Coltrin (Inactive) [ 05/Nov/13 ]

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

Comment by Travis Schneeberger [ 05/Nov/13 ]

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.

Comment by Jonathan Keller [ 21/Jul/14 ]

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.

Comment by Jonathan Keller [ 21/Jul/14 ]

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.

Comment by Jonathan Keller [ 21/Jul/14 ]

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...)

Comment by Jonathan Keller [ 21/Jul/14 ]

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.

Comment by Gayathri Athreya [ 21/Jul/14 ]

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.

Comment by Jonathan Keller [ 21/Jul/14 ]

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.

Comment by Jonathan Keller [ 21/Jul/14 ]

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.

Comment by Jonathan Keller [ 22/Jul/14 ]

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>

Comment by Gayathri Athreya [ 22/Jul/14 ]

Cool, thanks Jonathan. I will check it out.

Comment by Jonathan Keller [ 13/Aug/14 ]

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.

Comment by Kristina Taylor (Inactive) [ 25/Aug/14 ]

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.

Comment by Jonathan Keller [ 25/Aug/14 ]

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.

Generated at Mon Jun 01 11:39:56 CDT 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.