Thanks Jacopo. I haven't looked into the entity cache implementation
thoroughly, but I was under the impression that it can be configured to
be distributed.
I have the fix working on my local copy. As you can see, I have made
some related changes already and will be making some more, but I won't
commit the fix until next weekend - to give everyone a chance to respond.
-Adrian
On 4/22/2013 9:33 AM, Jacopo Cappellato wrote:
It seems actually to be an issue rather than a feature (I can't think of a use
case where this behavior would be useful); I have created a few test cases
(similar to the one you have provided in the other thread) that further analyze
your discovery but they don't add much to what you found (apart from confirming
the risk of getting stale data).
However, when we start design/implement a refactoring of this part of the
system, I would suggest that we also consider how to deal with similar
scenarios in a clustered deployment (in fact many of the production deployment
are based on clusters); the simplest use case could be: in a cluster, we have
two OFBiz instances connected to the same database; in one instance the list is
cached, in the other instance one of the generic values (that are part of the
selection) is updated. A distributed cache system may help here.
Jacopo
On Apr 21, 2013, at 10:54 AM, Adrian Crum <[email protected]>
wrote:
Last week I discovered a flaw in the EntityListCache implementation:
http://mail-archives.apache.org/mod_mbox/incubator-ofbiz-dev/201304.mbox/%[email protected]%3E
To summarize: Entity conditions that are cached become stale when any member of
the cached list is changed - making the cache contents invalid. In addition,
GenericValues in the cached list are mutable - which is inconsistent with the
primary key cache, where GenericValues from the cache are immutable.
I would like to fix this, but I think we should discuss it first.
One change would be to make the list member GenericValues immutable. This will make the
GenericValues retrieved from the entity list cache consistent with the GenericValues
retrieved from the primary key cache, but it won't prevent an invalid cache (because the
list member GenericValue can be cloned and modified). Also, this change will likely break
a lot of code, because it is common to retrieve a list of GenericValues from the cache
and then make changes to the list members. We could create a "transitional"
GenericValue that would warn developers when they modify a cached list member, and then
switch to an immutable GenericValue some time in the future.
To fix the stale cache problem, the cache instance can be made a GenericValue
listener in all of its list members - so any time a list member is modified the
cache will be cleared. This will keep the cache valid, but there might be a
performance hit. I'm open to other solutions to this problem.
Any thoughts?
-Adrian
