[infinispan-dev] Meaning of locking in Infinispan: ISPN-1546 and better general throughput

[Sanne Grinovero]

On 7 December 2011 16:00, Vladimir Blagojevic <vblagoje at redhat.com> wrote:
> On 11-12-07 10:27 AM, Sanne Grinovero wrote:
>>
>>
>> To solve ISPN-1546, I think it's totally fine to acquire a lock on the
>> FGAM for the time needed to create an iterator. But this lock needs to
>> be a different instance than the entry itself, and will be very short
>> lived, and not clustered in any way. it's just a means to guarantee we
>> can make a safe copy of the needed Array, and acquiring this lock
>> should have nothing to do with the "data experience" of preventing
>> some entries of the FGAM to be updated.
>>
>> thoughts?
>>
> In order to make these snapshot in case of FGAM I believe we need
> hierarchical locks. Besides each key in FGAM having its own lock we'd now
> need a lock for the entire FGAM. Do you agree?

Yes that's my thought as well, and this additional lock will not be
acquired for longer than what you need to make a consistent snapshot
- so it won't span multiple RPC requests for example, and will always
be very short so that it doesn't affect the "experienced semantics" of
the FGAM.

Sanne