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

Mircea Markus mmarkus at redhat.com
Wed Jul 10 08:51:01 EDT 2013


On 9 Jul 2013, at 13:48, Pedro Ruivo <pedro at infinispan.org> wrote:

> 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.

+1. 

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)







More information about the infinispan-dev mailing list