Scott Gray wrote: > On 6/12/2010, at 6:21 PM, Adam Heath 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. > > Thanks for pointing this out, I wasn't aware of it and I can think of a fair > few places where something like this could be put to use. Using it in place > of some of the recent fixes to caching of freemarker template objects > originating from Content records is the first that comes to mind.
I'm the one who wrote this feature years and years ago. However, there is a race condition. It's possible that between the time you fetch the list of generic values, and get around to storing the complex object graph, the original list of values has been cleared. The fix is to add some kind of concurrent api, putIfAbsent or some such. I haven't thought in detail about the fix, I just know the problem could happen in theory.
