The performance hit I envisioned was the overhead of notifying listeners
during store or remove. But I think I solved that with the custom
Observable class and some other optimizations I have in mind.
-Adrian
On 4/22/2013 11:02 AM, Jacques Le Roux wrote:
I guess indeed normally an event will be fired and the cache clearing
distributed
I'd ask for a bit of more time for the rest of us to have a deeper look but
from your explanation below this seems safe to me.
It would be good if we could measure, or at least have an idea about the order
of magnitude on, the performance implications
Thanks
Jacques
From: "Adrian Crum" <adrian.c...@sandglass-software.com>
The fix will be pretty simple - when a GenericValue is stored or
removed, any related entity condition caches (the ones the GenericValue
is a member of) will be cleared. So I'm assuming clearing a cache that
is distributed will clear all clustered caches. If you have access to a
test cluster, you can test it after the commit.
-Adrian
On 4/22/2013 10:19 AM, Jacopo Cappellato wrote:
On Apr 22, 2013, at 10:45 AM, Adrian Crum <adrian.c...@sandglass-software.com>
wrote:
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 don't remember the details but the issue you have discovered for sure also
happens in a clustered deployment; and the fix you are proposing would not
address the clustered deployment (if I am not missing something).
Jacopo
