<div dir="ltr">Pedro, I'll integrate the PR as it is, and then you can experiment with my proposal in another branch/PR.<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 9, 2013 at 1:48 PM, Pedro Ruivo <span dir="ltr"><<a href="mailto:pedro@infinispan.org" target="_blank">pedro@infinispan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
On 07/09/2013 11:46 AM, Galder Zamarreņo wrote:<br>
><br>
> On Jul 8, 2013, at 11:02 AM, Pedro Ruivo <<a href="mailto:pedro@infinispan.org">pedro@infinispan.org</a>> wrote:<br>
><br>
>> Hi guys,<br>
>><br>
>> re: ISPN-2840, ISPN-3235, ISPN-3236<br>
>> short: transaction isolation in repeatable read<br>
>><br>
>> Dan came up with an idea (a good idea IMO) to change a little the logic<br>
>> how entries are put in the context for transactional caches.<br>
>><br>
>> One of the Repeatable Read properties is after a key is accessed, the<br>
>> transaction should never see other concurrent transaction values, even<br>
>> if they commit first. In result, we can optimize the distributed mode by<br>
>> only do a remote get on the first time a transaction access a key.<br>
>><br>
>> My idea (and the one implemented in the Pull Request)<br>
><br>
> ^ Which pull req, link? You mean [1]?<br>
<br>
</div>yes<br>
<div class="im"><br>
><br>
> [1] <a href="https://github.com/infinispan/infinispan/pull/1937" target="_blank">https://github.com/infinispan/infinispan/pull/1937</a><br>
><br>
>> was adding a flag<br>
>> to mark the entry as accessed. All future access to that key will not<br>
>> try to fetch the data from container neither from a remote location (we<br>
>> have a small but with last one).<br>
>><br>
>> The Dan's idea is more simple but require some change in the<br>
>> EntryFactory logic.<br>
><br>
> ^ Which is Dan's idea exactly?<br>
<br>
</div>is the description below:<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
>> At this stage, we only put an entry in the<br>
>> transaction context if the following conditions are respected:<br>
>><br>
>> * the entry exists in data container (i.e. the node is owner or it is in L1)<br>
>> * we put a RepeatableReadEntry with null value in the transaction context if<br>
>> ** the entry does not exist in the container but the node is owner<br>
>> ** the entry does not exist in the data container but the command has<br>
>> flags to skip the remote fetch (like IGNORE_RETURN_VALUE or<br>
>> SKIP_REMOTE_LOOKUP). Of course the conditional commands needs special<br>
>> attention here.<br>
>><br>
>> Note: as usual, if the entry exists in the context, then nothing is done.<br>
>><br>
>> At the TxDistributionInterceptor level, the check to see if the remote<br>
>> get should be done is simple as check if lookupEntries(k)==null.<br>
>><br>
>> Dan, if I said something wrong let me know. If I was not clear at some<br>
>> point let me know too.<br>
>><br>
>> Anyone see any issue with this approach?<br>
>> Any other suggestions?<br>
>><br>
>> Cheers,<br>
>> Pedro Ruivo<br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
><br>
> --<br>
> Galder Zamarreņo<br>
> <a href="mailto:galder@redhat.com">galder@redhat.com</a><br>
> <a href="http://twitter.com/galderz" target="_blank">twitter.com/galderz</a><br>
><br>
> Project Lead, Escalante<br>
> <a href="http://escalante.io" target="_blank">http://escalante.io</a><br>
><br>
> Engineer, Infinispan<br>
> <a href="http://infinispan.org" target="_blank">http://infinispan.org</a><br>
><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div></div>