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

So in Infinispan we have a single type of lock associated with each entry; I assume it's designed like it is to save on memory, as are features like lock striping, and as the reason to not support both read and write locks. A problem I'm having more and more often, is that the "lock" is being used both as something that leaks out as a way to control data consistency from a "user" point of view, and as an internal artifact to ensure consistent internal mutations of our data structure. So the same Lock instance can be acquired for long term by a user process, and prevent for example the data to be passivated on a CacheLoader as this will attempt to grab the same lock. These should really be two different things! It might bring up some confusion as well, like with the FineGrainedAtomicMap: the feature I need is to be able to lock values in an atomic map individually, in terms of data consistency. This does NOT imply that Infinispan should not be allowed to acquire locks on the AtomicMap itself for brief moments, to proceed with other internal processes.. be it to create a threadsafe iterator, passivate the entry to a CacheLoader or even transfer the element to a new owned in the grid. Finally, to save memory I think that we don't need to guarantee these lock instances exists all the time; granted it might be more efficient to keep them as part of the Entry to avoid re-creating them too often, but in some cases it might not be the case, so we might even make it possible to create a different kind of Entry to optimise for specific usage patterns. In pratical terms, it's currently quite hard to design a consistent data access using Infinispan's locks from a user point of view if you have to consider that Infinispan might lock the keys for it's own internal needs. 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? Cheers, Sanne