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

[Pedro Ruivo]

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