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 <pe...@infinispan.org> wrote: > > > On 07/09/2013 11:46 AM, Galder ZamarreƱo wrote: > > > > On Jul 8, 2013, at 11:02 AM, Pedro Ruivo <pe...@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@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > > -- > > Galder ZamarreƱo > > gal...@redhat.com > > twitter.com/galderz > > > > Project Lead, Escalante > > http://escalante.io > > > > Engineer, Infinispan > > http://infinispan.org > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev