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

[Pedro Ruivo]

fine by me :)

On 07/09/2013 05:44 PM, Dan Berindei wrote:
> Pedro, I'll integrate the PR as it is, and then you can experiment with
> my proposal in another branch/PR.
>
>
> On Tue, Jul 9, 2013 at 1:48 PM, Pedro Ruivo <pedro at infinispan.org
> <mailto: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
>     <mailto: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
>     <mailto:infinispan-dev at lists.jboss.org>
>      >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>      >
>      > --
>      > Galder Zamarreño
>      > galder at redhat.com <mailto:galder at redhat.com>
>      > twitter.com/galderz <http://twitter.com/galderz>
>      >
>      > Project Lead, Escalante
>      > http://escalante.io
>      >
>      > Engineer, Infinispan
>      > http://infinispan.org
>      >
>      >
>      > _______________________________________________
>      > infinispan-dev mailing list
>      > infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>