We have also notice that the cache can get polluted with contents from a rolledback transaction!! Also, the visibility of the objects doesn't respect the transaction boundaries....
This has caused some problems, we haven't fixed it yet.... so no patch to contribute... sorry. ----- "Adam Heath" <[email protected]> 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' > > 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. 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.
