[infinispan-dev] tx optimizations

[Mircea Markus]

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.

>> 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)
>
>>
>> Wdyt?
>>
>> Cheers,
>> Mircea
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> Lead, JBoss Cache
> http://www.jbosscache.org
> manik at jboss.org <mailto:manik at jboss.org>
>
>
>
>