[infinispan-dev] Functionality based on configuration

[Radim Vansa]

On 11/24/2014 12:44 PM, Dan Berindei wrote:
> Hi Radim
>
> First of all, I don't think this is feasible. For example, 
> read-committed vs repeatable read changes how the entries are stored 
> in the transaction context, so you can't have a repeatable-read get() 
> in the same transaction after a read-committed get. Write skew check 
> also requires versions, so you couldn't skip updating the version in 
> any optimistic cache just in case some transaction might need it in 
> the future.

The isolation level is a property of transaction, not single operation: 
you should specify this ahead in the transactional context before doing 
any operations (I would imagine API like 
AdvancedCache.getTxCache(LockingMode.OPTIMISTIC, 
IsolationLevel.REPEATABLE_READ)).

>
> We also can't mix non-transactional, transactional asynchronous, and 
> transactional synchronous operations on the same cache, as they would 
> break each other's consistency. In fact, Infinispan 4.x allowed both 
> transactional and non-transactional operations on the same cache, but 
> at some point we realized that there's no way to ensure the 
> consistency of transactions if there are overlapping with 
> non-transactional operations.

Just out of curiosity - Hazelcast allows mixing transactional and 
non-transactional code, do you know how they do it? Coherence has also 
all transactions API-wise (but I was not able to get them working). But 
I agree that allowing both tx and non-tx operations could complicate 
things a lot (the number of cases that need to be designed and tested 
grows exponentially with each option).

>
> I agree that the configuration is very tightly coupled with the code 
> that uses it, so settings that can break the application should be 
> more obvious. We should discuss how we can improve this at the 
> clustering meeting in Berlin.
>
> But I think forgetting to add a flag in some part of the application 
> is just as likely as the administrator making a mistake in the 
> configuration, and having different consistency models in the same 
> cache can also make code harder to understand. So instead of allowing 
> flags to control consistency, I would rather add methods for the user 
> to assert that the cache has certain properties.

IMO the probability that two people (programmer who did not write 
documentation and administrator who did not read the code) make a 
mistake because of configuration is still larger than the one of single 
person.

Thanks for comments

Radim

>
> Cheers
> Dan
>
>
> On Fri, Nov 21, 2014 at 12:38 PM, Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>> wrote:
>
>     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 <mailto:rvansa at redhat.com>>
>     JBoss DataGrid QA
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20141124/2d77419d/attachment.html