Re: [infinispan-dev] tx optimizations

Manik Surtani wrote: > > On 6 Apr 2009, at 15:26, Mircea Markus wrote: > >> Manik Surtani wrote: >>> >>> On 3 Apr 2009, at 20:33, Mircea Markus wrote: >>> >>>> Hi, >>>> >>>> Here are two optimizations that can be implemented in our 2PC >>>> model: >>>> 1) if there are only two members int the cluster use an 1PC (or >>>> if you only replicate to one buddy, like in buddy replication). >>>> If the 1st phase fails remotely, then also rollback locally. >>>> This would reduce one network roundtrip. >>> >>> Interesting. I assume with BR you mean DIST where a key is >>> mapped on to 1 other peer - Infinispan won't support BR as in >>> JBC. ;-) >>> >>> While this is an interesting thought, it does raise the potential >>> for race conditions - since this decision will have to be taken >>> in the TxInterceptor in the beforeCompletion phase of a >>> transaction, and by the time the call gets to the interceptor for >>> replication, the topology may have changed such that you need to >>> replicate to 2 instead of 1 other peer. Which would mean a 2PC >>> again. So it does need some thought. >> Good point with concurrency. Even so, this is a valid optimization >> and I think worths thinking about it. > > Yes, of course. I just pointed out one of the challenges that came > to mind. > >>>> 2) when asked to prepare, a participant might return a value >>>> indicating that no changes were made (read-only participant), so >>>> this one won't need an commit message, so less roundtrip. >>> >>> No, prepares only contain modifications. Read commands don't >>> get added to a prepare, >> I know that :) >>> and if a prepare doesn't contain any writes, it isn't broadcast >>> economising on the network call. >> e.g. a bunch of remove() operations on keys that does not exist >> would cause an "read only" participant. There are other ops that >> might not modify the remote node, e.g. putIfAbsent, replace(k,v) > > Yes, but we need to be sure the behaviour of all of these commands > are the same cluster-wide. And they may not be. E.g., a remove() > may be a no-op on one node due to eviction, but on the neighbour it > may actually remove something. Same with pIA() and replace(). The optimization I described refers to an individual node. If a node responds with "READ_ONLY" to a prepare message, then we won't have to send an commit/rollback message to that node only, disregarding the way other nodes responded.