On Dec 5, 2010, at 8:11 PM, Adam Heath wrote: > David E Jones 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... > > I've got a change queued that has deprecated getRelatedOne(as > suggested earlier). While doing that, I also decided to go thru and > fix all the remaining findByPrimaryKey, replacing with findOne. > During that change, I noticed several FooWorker/FooHelper, that should > really be using caching variants.
Yes, I don't doubt that there is code in OFBiz that could leverage caching more effectively. > A read-only fetch should be cached. A read-only web request should > never hit the database. Where do these rules come from? How did they become rules? > If it's a question of memory, and a > particular install is throwing away cache entries too quickly, then > that install needs more memory. I guess my points weren't very good if that's all the rebuttal you thought was needed. How about this case: running a little ecommerce site with 100,000 customers. The typical customer visits the site around once per week, though some customers rarely visit the site, maybe a few times per year. A customer logs in, and looks their customer profile, which is 100% read-only (not data is changed as the page loads). They may look at the profile page again if they decide to edit something, but generally will not otherwise. Should all of the data on the profile be cached so that on repeated views we can follow your two rules above (read-only data cached, read-only web request never hit the database (I assume after the first hit, of course))? So, we should all of the customer's contact, order, contact/mailing list, etc information all cached? How much memory are you thinking of... something roughly the same size as the database? Or is the whole point of this to try to argue for in-memory databases... yeah... I see where you're going... And, BTW, this isn't some weird case... for most data in an ERP or ecommerce system this IS the case. In other words, it has a low reads/time-period rate, and a low read to update ratio, and therefore caching is a waste of system resources and more likely to cause issues with bad/stale data (especially across multiple app servers... unless you want to keep all caches perfectly in sync all the time and take the performance hit from that goal, especially making sure other caches are updated before you commit, ie involve the caches in the 2-phase commit so that they are all updated before the data can be committed to the db). -David
