with the old version of ehcache (1.2) we used to get concurrent modification exceptions which was fixed in the later releases. (the reason why we upgraded the ehcache version)
userService.getAllRoles() would load all the roles onto the cache and other load calls will start using it.
We are still tied down on what to use as an effective tool for testing the benefit of caching.
Could we take this on a phased approach?
What i mean is something like Role looked like an obvious choice because of the frequency of use (users logging in) low modifications (although the directive "cache-write" handles this transparently)
We can identify objects like that to start integrating with the cache.
If we look at the tests, the cache elegantly handles object modifications if we use the option cache=read-write option. So the switch should be transparent
New Feature
Code Review (Pre-Commit)
Must
Step 1: start caching Concepts.
Other good candidates: Patients, other metadata (location, concept_datatype, encounter_type)
Also: explain how does caching works, for the benefit of other OpenMRS developers who aren't going to follow this closely. For example with bulk queries: if we were caching observations, and we select all obs for a patient, do they all get cached? What if we first select all weight obs, and then select all obs. Is the second query sped up by the caching? Would we have done better reversing the order of the queries.