[infinispan-dev] Functionality based on configuration

Radim Vansa rvansa at redhat.com
Fri Nov 21 05:38:53 EST 2014


Hi,

when thinking about strong/eventual consistency and ease of 
configuration, I was considering whether cache configuration should 
affect results of operations at all (one example could be read 
committed/repeatable read, or write skew check).

It would seem to me that the configuration would be simpler, and user 
options more rich if those options that change the result of operation 
would be purely API-wise (based on flags or method arguments) and the 
configuration could only change the performance (defining cache store 
will slow down some operations) or availability of these operations (you 
cannot start a transaction when the manager is not defined), not the 
outcome.

E.g. is there really a point to be able to change sync/async 
configuration of the cache when the code expects strong consistency? If 
it can handle that, it should grab cache.withFlags(FORCE_ASYNCHRONOUS) 
and work on that.
Another example is in the strong/eventual consistency - if I want to see 
the cache as strongly consistent, I can't read from backup owners [1]. 
Currently there is no option to force reading from primary owner, 
therefore, I was wondering whether it should be configurable (together 
with staggered gets policy - not that this would be implemented) or 
whether that should be specified as a flag - and it seems to me that it 
should not be configurable as the administrator could remove the flag 
from the config (and see increased performance) but eventually a race 
could occur where this flag matters and the application will behave 
incorrectly.

WDYT? This question is obviously rather for changes on the roadmap (I'd 
say along with leaving ConcurrentMap interface) than any immediate 
actions in versions 7.x or 8.x.

Radim

[1] https://issues.jboss.org/browse/ISPN-4995

-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA



More information about the infinispan-dev mailing list