Re: Java-level locks on cache entries

2017-09-12 Thread John Wilson
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

2017-09-12 Thread Konstantin Dudkov
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

2017-09-11 Thread John Wilson
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,