Ah, it's quite a large edge case IMO On Thu, Mar 19, 2015 at 12:20 AM, Adrian Crum < [email protected]> wrote:
> That is the edge case I mentioned. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 3/19/2015 6:54 AM, Scott Gray wrote: > >> 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 >>> >>> >>
