[infinispan-dev] Functionality based on configuration

Dan Berindei dan.berindei at gmail.com
Mon Nov 24 10:54:43 EST 2014


Hi Radim

Please make sure you reply in plain text mode, the replies got a bit mixed up.

On Mon, Nov 24, 2014 at 3:07 PM, Radim Vansa <rvansa at redhat.com> wrote:
>
> 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)).
>

How would you handle something like this?

public void someMethod() {
  tm.begin()
  txCache = manager.getCache().getTxCache(LockingMode.OPTIMISTIC,
IsolationLevel.REPEATABLE_READ);
  txCache.put("k1", "v1");
  anotherMethod();
  tm.commit()
}

public void anotherMethod() {
  nontxCache = manager.getCache().getNonTxCache();
  nontxCache.put("k2", "v2");
}

>
>> 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 suspect they use the same locking + replication strategy for non-tx
caches as they use for tx caches, just without the link to an external
transaction. I wish we would do the same, but I'm not sure we could
keep the performance as good as the actual non-tx performance.

>
>> 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.
>

Who said there's only one programmer? :)

Even if there is a single person writing (or reading) the code, I
think it's better to have a single place where you can look and see
how a cache is expected to behave instead of having to check all the
places where that cache is used. And a paranoid programmer can protect
himself from the administrator by configuring the cache
programmatically...

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



More information about the infinispan-dev mailing list