[KULRICE-154] improve kuali caching solution Created: 11/Mar/07  Updated: 06/Sep/12  Resolved: 02/Apr/12

Status: Closed
Project: Kuali Rice Development
Component/s: Configuration, Development
Affects Version/s: None
Fix Version/s: 2.0

Type: Improvement Priority: Critical
Reporter: Dan Lemus (Inactive) Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates KFSOLD-10964 Experiment with improved caching impl... Closed
Similar issues:
KULRICE-5357update our caching solution for rice.
KULRICE-11177Need JPA related caching functionality to improve performance and support clustering
KULRICE-3222Ensure that ParameterServerService can be remoted and improve caching in ParameterServiceProxyImpl
KULRICE-8327Implement caching for Message Service
KULRICE-1512improve configurability of drop-down value caching
KULRICE-5100StyleServiceImpl.getStyle should perform caching of styles
KULRICE-5997Parameter cache keys need to be changed
KULRICE-4410For doc search, don't call new initiator caching code if there is no search results
KULRICE-8955MessageServiceImpl getDefaultLocaleCode Caching
KULRICE-5942See if we can improve our cache flushing with new Spring cache annotations
Application Requirement:
KFS

 Comments   
Comment by Ailish Byrne [ 18/Feb/08 ]

i guess this isn't required for release 3. jonathan did a bit to speed things up. and, we can see where we're at after jpa. but, it seems like we should really make it a priority to get something this basic figured out soon

Comment by Eric Westfall [ 18/Feb/08 ]

This comment is more of a question for Nate. Does JPA support any sort of caching concepts? Seems this issue is primarly tied to caching at the ORM layer which I know both Hibernate and OJB support (including a second level cache) but I'm not sure how that translates into the OJB world (or if it's vendor-specific regardless).

Comment by Nate Johnson (Inactive) [ 18/Feb/08 ]

Caching is vendor specific. The QL seems richer in JPA than in OJB, but that's not caching.

Comment by Ailish Byrne [ 18/Feb/08 ]

we've been looking for something better than what we've got for method level caching for a while now, too

Comment by Eric Westfall [ 18/Feb/08 ]

I suppose we could provide an out-of-the-box implementation of second level caching for Hibernate which plugs into the KSB and OSCache for distributed cache flush. That way applications implementing Rice could use that if they so chose. It would certinaly make it easier to configure this type of ORM cache in a cluster-safe environment. This seems like more a value-added item though so I think "Wish List" is appropriate.

Comment by Aaron Hamid (Inactive) [ 18/Feb/08 ]

We might want to investigate Terra Cotta. http://www.terracotta.org/

One question is its license, which is a variant of MPL:

http://www.terracotta.org/confluence/display/wiki/FAQ#FAQ-LicensingFAQ

Comment by Ailish Byrne [ 18/Feb/08 ]

sorry, i just want to make sure i'm understanding this correctly. when we move to jpa, we will have a replacement for the current ojb persistence broker caching we now do right, even though it will be a vendor specific implementation, our projects will be set up to use it?

Comment by Nate Johnson (Inactive) [ 19/Feb/08 ]

If you are referring to the per broker cache, then yes, we will have that out of the box and that is not vendor specific. It's part of the API and is called a persistence context.

I guess the vendor specific caching I was referring to would be a 2nd level cache... OJB sorta supports that concept, though I've never seen it work well in a distributed environment.

Comment by Ailish Byrne [ 19/Feb/08 ]

cool - thanks for the clarification!

Comment by Jessica Coltrin (Inactive) [ 02/Apr/12 ]

Caching was redone in Rice 2.0 and should address the items in this old Jira.

Generated at Fri Apr 03 12:20:02 CDT 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.