I tend to disagree with the "cache everything" approach because the cache isn't transaction aware. If you: 1. update a record 2. select that same record 3. encounter a transaction rollback
Then the cache will still contain the changes that were rolled back. Regards Scott On Wed, Mar 18, 2015 at 5:16 AM, Adrian Crum < [email protected]> wrote: > I would like to share some insights into the entity cache feature, some > best practices I like to follow, and some related information. > > Some OFBiz experts may disagree with some of my views, and that is okay. > Different experiences with OFBiz will lead to different viewpoints. > > The OFBiz entity caching feature is intended to improve performance by > keeping GenericValue instances in memory - decreasing the number of calls > to the database. > > Background > ---------- > > Initially, the entity cache was very unreliable due to a number of flaws > in its design and in the code that calls it (it was guaranteed to produce > stale data). As a result, I personally avoided using the entity cache > feature. > > Some time ago, Adam Heath did a lot of work on the entity cache. After > that, Jacopo and I did a lot of work fixing stale data issues in the entity > cache. Today, the entity cache is much improved and unit tests ensure it > produces the correct data (except for one edge case that Jacopo has > identified). > > I mention all of this because the previous quirky behavior led to some > "best practices" that didn't make much sense. A search through the OFBiz > mail archives will produce a mountain of conflicting and confusing > information. > > Today > ----- > > Since the current entity cache is reliable, there is no reason NOT to use > it. My preference is to make ALL Delegator calls use the cache. If all code > uses the cache, then individual entities can have their caching > characteristics configured outside of code. This enables sysadmins to > fine-tune entity caches for best performance. > > [Some experts might disagree with this approach because the entity cache > will consume all available memory. But the idea is to configure the cache > so that doesn't happen.] > > If you code Delegator calls to avoid the cache, then there is no way for a > sysadmin to configure the caching behavior - that bit of code will ALWAYS > make a database call. > > If you make all Delegator calls use the cache, then there is an additional > complication that will add a bit more code: the GenericValue instances > retrieved from the cache are immutable - if you want to modify them, then > you will have to clone them. So, this approach can produce an additional > line of code. > > > -- > Adrian Crum > Sandglass Software > www.sandglass-software.com >
