Re: Java-level locks on cache entries
That one is for locking pages while a check point process is going on. Thanks, On Tue, Sep 12, 2017 at 6:57 AM, Konstantin Dudkov wrote: > Hi, > > Ignite uses page-level locks, see > https://github.com/apache/ignite/blob/43be051cd33f0e35a5bf05fa3dbe73 > 660d2dcdd2/modules/core/src/main/java/org/apache/ignite/ > internal/processors/cache/persistence/tree/util/PageHandler.java#L245 > > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Re: Java-level locks on cache entries
Hi, Ignite uses page-level locks, see https://github.com/apache/ignite/blob/43be051cd33f0e35a5bf05fa3dbe73660d2dcdd2/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/tree/util/PageHandler.java#L245 -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Java-level locks on cache entries
Hi, The code path of a cache operation, e.g. cache.put(key, value), involves locking the entry (entries) at java-level: https://github.com/apache/ignite/blob/788adc0d00e0455e06cc9acabfe9ad425fdcd65b/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridDhtAtomicCache.java#L2845 Also, the locking is released only after the serialization and the ultimate writing of the cache entry (entries) into the off-heap data page. My question: if the locking is at java-level, how do we avoid the conflict of many threads writing to the same data page offset? Or is it the case that, before a lock is acquired, the offset within the data page that the entry will be written to is known? Thanks,