On Jul 8, 2013, at 11:02 AM, Pedro Ruivo <pedro(a)infinispan.org&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño galder(a)redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)infinispan.org <mailto:pedro@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(a)infinispan.org <mailto:pedro@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(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Galder Zamarreño > galder(a)redhat.com <mailto:galder@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(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev