[infinispan-dev] Isolation level in Repeatable Read + remote get
Galder Zamarreño
galder at redhat.com
Tue Jul 9 06:46:23 EDT 2013
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]?
[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?
> 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
More information about the infinispan-dev
mailing list