<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/24/2014 12:44 PM, Dan Berindei
wrote:<br>
</div>
<blockquote
cite="mid:CA+nfvwT1T2W=3bMaBSHAoLP13SLVvYknjzL45fQLYs2c-eUwVg@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Radim
<div><br>
</div>
<div>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. <br>
</div>
</div>
</blockquote>
<br>
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)).<br>
<br>
<blockquote
cite="mid:CA+nfvwT1T2W=3bMaBSHAoLP13SLVvYknjzL45fQLYs2c-eUwVg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
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).<br>
<br>
<blockquote
cite="mid:CA+nfvwT1T2W=3bMaBSHAoLP13SLVvYknjzL45fQLYs2c-eUwVg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
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.<br>
<br>
Thanks for comments<br>
<br>
Radim<br>
<br>
<blockquote
cite="mid:CA+nfvwT1T2W=3bMaBSHAoLP13SLVvYknjzL45fQLYs2c-eUwVg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Cheers</div>
<div>Dan</div>
<div><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Nov 21, 2014 at 12:38 PM,
Radim Vansa <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
when thinking about strong/eventual consistency and ease
of<br>
configuration, I was considering whether cache
configuration should<br>
affect results of operations at all (one example could be
read<br>
committed/repeatable read, or write skew check).<br>
<br>
It would seem to me that the configuration would be
simpler, and user<br>
options more rich if those options that change the result
of operation<br>
would be purely API-wise (based on flags or method
arguments) and the<br>
configuration could only change the performance (defining
cache store<br>
will slow down some operations) or availability of these
operations (you<br>
cannot start a transaction when the manager is not
defined), not the<br>
outcome.<br>
<br>
E.g. is there really a point to be able to change
sync/async<br>
configuration of the cache when the code expects strong
consistency? If<br>
it can handle that, it should grab
cache.withFlags(FORCE_ASYNCHRONOUS)<br>
and work on that.<br>
Another example is in the strong/eventual consistency - if
I want to see<br>
the cache as strongly consistent, I can't read from backup
owners [1].<br>
Currently there is no option to force reading from primary
owner,<br>
therefore, I was wondering whether it should be
configurable (together<br>
with staggered gets policy - not that this would be
implemented) or<br>
whether that should be specified as a flag - and it seems
to me that it<br>
should not be configurable as the administrator could
remove the flag<br>
from the config (and see increased performance) but
eventually a race<br>
could occur where this flag matters and the application
will behave<br>
incorrectly.<br>
<br>
WDYT? This question is obviously rather for changes on the
roadmap (I'd<br>
say along with leaving ConcurrentMap interface) than any
immediate<br>
actions in versions 7.x or 8.x.<br>
<br>
Radim<br>
<br>
[1] <a moz-do-not-send="true"
href="https://issues.jboss.org/browse/ISPN-4995"
target="_blank">https://issues.jboss.org/browse/ISPN-4995</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Radim Vansa <<a moz-do-not-send="true"
href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>><br>
JBoss DataGrid QA<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/infinispan-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</font></span></blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
infinispan-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Radim Vansa <a class="moz-txt-link-rfc2396E" href="mailto:rvansa@redhat.com"><rvansa@redhat.com></a>
JBoss DataGrid QA
</pre>
</body>
</html>