[infinispan-dev] locking optimisations reloaded

[Manik Surtani]

Good summary, Mircea.  Breaking it down - and the specific design as well in the JIRAs - makes it seem almost trivial to implement.  ;)

On 24 May 2011, at 22:36, Mircea Markus wrote:

> Hi,
> 
> This is re: http://community.jboss.org/wiki/PossibleLockingImprovements
> 
> I've created JIRAs for the locking optimisations as follows:
> 
> #1: https://issues.jboss.org/browse/ISPN-1131

Keep in mind the LockingInterceptor delegates a lot of the copyOnWrite (of CacheEntries) and the corresponding locking to the EntryFactoryImpl.  This too would probably need to be subclassed.

> #2: this seems to be just a particular case of #4 
> #3: https://issues.jboss.org/browse/ISPN-1132

Looks good, however I'm concerned about the key comparator and how this would deterministically order keys.  Basing order on hashcode can lead to collisions (and if using the default Object.hashcode breaks down completely).  And we can't *require* that users provide one; we'd need to provide a sensible - if suboptimal - default.

> #4: https://issues.jboss.org/browse/ISPN-1137

Paolo's concerns are very valid.  Vector clocks to determine order of application on non-primary owner node is one mechanism that would work; another may be that each node only ever communicates with the primary owner.  And the primary owner then has the responsibility of propagating prepares and commits to other peers.  This will mean eventual consistency though, since concurrent readers would always have to read from the primary owner since reading from other owners of an entry may result in stale data.

Another potential problem here is failover.  You should discuss how you intend to deal with failure in the primary owner, with different transactions at various stages of completion.

Cheers
Manik
--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110609/d03efe6d/attachment.html