[infinispan-dev] Isolation level in Repeatable Read + remote get

[Pedro Ruivo]

On 07/09/2013 11:46 AM, Galder Zamarreño wrote:
>
> On Jul 8, 2013, at 11:02 AM, Pedro Ruivo <pedro at infinispan.org> wrote:
>
>> Hi guys,
>>
>> re: ISPN-2840, ISPN-3235, ISPN-3236
>> short: transaction isolation in repeatable read
>>
>> Dan came up with an idea (a good idea IMO) to change a little the logic
>> how entries are put in the context for transactional caches.
>>
>> One of the Repeatable Read properties is after a key is accessed, the
>> transaction should never see other concurrent transaction values, even
>> if they commit first. In result, we can optimize the distributed mode by
>> only do a remote get on the first time a transaction access a key.
>>
>> My idea (and the one implemented in the Pull Request)
>
> ^ Which pull req, link? You mean [1]?

yes

>
> [1] https://github.com/infinispan/infinispan/pull/1937
>
>> was adding a flag
>> to mark the entry as accessed. All future access to that key will not
>> try to fetch the data from container neither from a remote location (we
>> have a small but with last one).
>>
>> The Dan's idea is more simple but require some change in the
>> EntryFactory logic.
>
> ^ Which is Dan's idea exactly?

is the description below:

>
>> At this stage, we only put an entry in the
>> transaction context if the following conditions are respected:
>>
>> * the entry exists in data container (i.e. the node is owner or it is in L1)
>> * we put a RepeatableReadEntry with null value in the transaction context if
>> ** the entry does not exist in the container but the node is owner
>> ** the entry does not exist in the data container but the command has
>> flags to skip the remote fetch (like IGNORE_RETURN_VALUE or
>> SKIP_REMOTE_LOOKUP). Of course the conditional commands needs special
>> attention here.
>>
>> Note: as usual, if the entry exists in the context, then nothing is done.
>>
>> At the TxDistributionInterceptor level, the check to see if the remote
>> get should be done is simple as check if lookupEntries(k)==null.
>>
>> Dan, if I said something wrong let me know. If I was not clear at some
>> point let me know too.
>>
>> Anyone see any issue with this approach?
>> Any other suggestions?
>>
>> Cheers,
>> Pedro Ruivo
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>