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

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)

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.

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