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 <[email protected]
<mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>>
JBoss DataGrid QA
_______________________________________________
infinispan-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <[email protected]>
JBoss DataGrid QA
_______________________________________________
infinispan-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
