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 <rva...@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 <rva...@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 <rva...@redhat.com>
>> JBoss DataGrid QA
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> --
> Radim Vansa <rva...@redhat.com>
> JBoss DataGrid QA
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
