On Mar 22, 2010, at 1:52 PM, Adam Heath wrote: > David E Jones wrote: >> On Mar 22, 2010, at 11:07 AM, Adam Heath wrote: >> >>> Michael Xu (xudong) wrote: >>>> hi Adam, >>>> >>>> Thanks for your work. Cache layer is critical for ofbiz as ERP system. >>>> >>>> Just one quick question: There are a lot of cache frameworks (Personally I >>>> like Apache JCS very much) out there. Why ofbiz has to have its own >>>> implement? >>>> >>>> In my opinion, we have two ways to reduce bugs. Write more test codes, or >>>> write less product codes. Maybe we can replace ofbiz components with some >>>> existing components (say cache) or separate ofbiz components as sub >>>> projects >>>> or just totally new project to attract more projects to use (say, entity >>>> engine). >>> I've looked at ehcache, and have plans to convert to that eventually. >>> First, however, is to get our code functionting correctly, with no >>> bugs, and with good test cases on the existing interface(UtilCache), >>> then the implementation underneath can be switch, while keeping the >>> same set of test cases. >> >> I looked around a bit recently to see if there was a cache project that >> could replace the UtilCache stuff. >> >> OSCache and Ehcache both look pretty good, and Jakarta JCS looks okay, and >> of the various I read about Ehcache looks like the most feature-rich >> (especially for distributed caches and such). Ehcache also tracks statistics >> much like the OFBiz UtilCache stuff does. >> >> None of these appear to support soft-reference cache entries, but maybe >> that's not a big deal and it would be better to do size/entries limiting >> instead anyway (they all have good eviction algorithms). >> >> Are there any other cache projects that other people like? >> >> Should we deprecate the soft-reference support in order to more easily >> plugin a separate cache library? > > ehcache has soft-ref support. Do a google search for 'ehcache > softreference'
Sorry, I looked through a few things and I'm not seeing it. > Replacing UtilCache is not a good plan. It's best to keep that > api(with maybe a small change, if needed). Then swap out what > UtilCache does under the scenes, based on what we decide. Is there any possibility that this is what I meant? It is the only logical way after all... -David > But, as I > said, before we can do that, we need to test the current design, so > that when/if we do change, we can know that we haven't broken anything > that's already being tested.
