Hi Adrian, How would this work in a clustered or load balanced environment? With multiple nodes always checking their own local caches incorrect data would be persisted all the time.
Regards, Rupert On 18 March 2015 at 12:16, Adrian Crum <adrian.c...@sandglass-software.com> 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 > -- Rupert Howell Provolve Ltd Front Office, Deale House, 16 Lavant Street, Petersfield, GU32 3EW, UK t: 01730 267868 / m: 079 0968 5308 e: ruperthow...@provolve.com w: http://www.provolve.com
