+1 On Mar 18, 2015, at 5:16 PM, Jacques Le Roux <[email protected]> wrote:
> If a such effort would be undertaken, I'd prefer to go with ehcache: > http://ehcache.org/documentation/2.6/get-started/about-distributed-cache > > Jacques > > Le 18/03/2015 14:27, Adrian Crum a écrit : >> I agree there is a lot of overhead with the current distributed cache >> clearing implementation. From my perspective, that should be changed to use >> RMI - where the caches talk directly to each other. >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 3/18/2015 1:21 PM, Rupert Howell wrote: >>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>> >>
