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. Entity data that changes frequently should not be cached - because caching it leads to concurrency issues. -Adrian --- On Sun, 12/5/10, David E Jones <d...@me.com> wrote: > There are other reasons why you might not want to cache > something. Quite a few of them, even without trying to be > too creative. > > For example: memory use. Why cache things like contact mech > or order information that isn't likely to be read a very > many times, but if cached would take up memory until expired > and cleared (and would only be cleared if something is > cleaning up expired entries) or until it makes it to the end > of the LRU queue or whatever, and the whole time requiring > additional resources to keep track of and making more > legitimate caching less efficient. > > Another example: freshness. If you want to be sure the data > is good, get it from the db. If it won't cause big problems > to have stale data, then the cache is okay. > > Am I the only one who things caching everything by default > (as Marc suggested) or popping out warning messages (as Adam > suggests here) is a little crazy? I haven't seen anyone else > speak up, so just wondering... > > -David > > > On Dec 5, 2010, at 7:45 PM, Adam Heath wrote: > > > I've noticed several places in the code that issue a > findOne(or other > > find method), without using a cache, but then don't do > any > > modifications to the returned value. Such call > sites should really > > use a caching variant of the delegator. > > > > What I'd like to work on, is a feature, only used > during development, > > that would record any value looked up that wasn't > cached, and wasn't > > later modified, and print a warning, with an > exception, to allow for a > > caching variant to be added. Would others find > this useful? > > > > Obviously, it would need to be transaction based, and > would sometimes > > have false-positives. Additionally, if no > transaction is active, then > > that automatically means a caching variant should be > used. > >
