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 <
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
