ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Le Roux <jacques.le.r...@les7arts.com>
Subject Re: Entity Caching
Date Wed, 18 Mar 2015 16:16:48 GMT
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


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 <adrian.crum@sandglass-software.com>
>> 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
>>>>> 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
>>>>> 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
>>>>> 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,
>>>>> you will have to clone them. So, this approach can produce an additional
>>>>> line of code.
>>>>> -- 
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com

View raw message