Yes I'm aware of this. If everything was cached Surely every persist would need to trigger a JMS message telling all the other servers to dump their local cache. This overhead would be big, the amount of messages flying out would be hugely increased and the caches would be redundant anyway because they'd be constantly being dumped. It doesn't seem scalable.
On 18 March 2015 at 12:49, Adrian Crum <[email protected]> wrote: > A clustered environment must use distributed cache clearing. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 3/18/2015 12:34 PM, Rupert Howell wrote: > >> 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.crum@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: [email protected] w: http://www.provolve.com
