The translation to English is not good, but I think I understand what
you are saying.
The entity values in the cache MUST be immutable - because multiple
threads share the values. To do otherwise would require complicated
synchronization code in GenericValue (which would cause blocking and
hurt performance).
When I first starting working on the entity cache issues, it appeared to
me that mutable entity values may have been in the original design (to
enable a write-through cache). That is my guess - I am not sure. At some
time, the entity values in the cache were made immutable, but the change
was incomplete - some cached entity values were immutable and others
were not. That is one of the things I fixed - I made sure ALL entity
values coming from the cache are immutable.
One way we can eliminate the additional complication of cloning
immutable entity values is to wrap the List in a custom Iterator
implementation that automatically clones elements as they are retrieved
from the List. The drawback is the performance hit - because you would
be cloning values that might not get modified. I think it is more
efficient to clone an entity value only when you intend to modify it.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 3/19/2015 4:19 PM, Nicolas Malin wrote:
Le 18/03/2015 13:16, Adrian Crum a écrit :
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.
I don't see any logical reason why we need to keep a GenericValue came
from cache as immutable. In large vision, a developper give information
on cache or not only he want force the cache using during his process.
As OFBiz manage by default transaction, timezone, locale, auto-matching
or others.
The entity engine would be works with admin sys cache tuning.
As example delegator.find("Party", "partyId", partyId) use the default
parameter from cache.properties and after the store on a cached
GenericValue is a delegator's problem. I see a simple test like that :
if (genericValue came from cache) {
if (value is already done) {
getFromDataBase
update Value
}
else refuse (or not I have a doubt :) )
}
store
Nicolas
