--- On Sun, 12/5/10, Adam Heath <doo...@brainfood.com> wrote:
> Adrian Crum wrote:
> > I agree with David. An example is the advice he gave
> me during the development of temporal expressions.
> >
> > I wanted to cache the temporal expression Java
> structures in memory. David suggested getting the persisted
> expressions from the entity cache instead. Thinking about
> it, that made sense - temporal expressions should not change
> frequently so they are good candidates for entity caching.
>
> Storing them in the entity cache *is* storing them in
> memory. Are you
> iterating the entity values, building up some complex
> object? If so,
> then use Delegator.getCache().put(String, EntityCondition,
> String,
> Object). That allows you to add a complex built-up
> java object into
> the same internal cache that is storing the list of cached
> results
> from a condition lookup.
>
> > Entity data that changes frequently should not be
> cached - because caching it leads to concurrency issues.
>
> Well, duh. This feature would be used to find values
> that are being
> looked up repeatedly, not changing, and not being
> cached. How else
> would it be used?
I admit, I confused this thread with another and went off on a tangent. Some
kind of performance metric attached to the entity caching mechanism would be
worthwhile - so one could use the entity cache only where needed.
-Adrian
