Hi John,

1. No, content modification require lock holding to page to provide
consitency in multithreaded environment.
2. Page is locked for read before reading its content, and unlocked after.
Same for lock for write for writting. 1 writer or N readers allowed for
page. On unlock write lock, dirty flag for page may be set if there data
was actually modified.
3. Lock has per-page basis, additional striping by any offest within page
is not required accoring to tests.

Only one contention is observed sometimes in high load test, it is
contention of threads to lock to durable memory region segment. But this
situation can be handled by setting concurrenclyLevel in

Dmitriy Pavlov

вт, 13 февр. 2018 г. в 9:56, John Wilson <sami.hailu...@gmail.com>:

> Hi,
> Ignite documentation talks about entry-level locks and the page structure
> has a LOCK_OFFSET that I assume is used to store tag info. I have these
> questions.
>    1. Does Ignite use a lock-free implementation to lock pages and/or
>    entries?
>    2. When is a page locked and when is it released?
>    3. When an entry is inserted/modified in a page, is the page locked
>    (forbidding other threads from inserting entries in the page)? or only
> the
>    entry's offset is locked? (allowing other threads to insert/modify other
>    items)
> Thanks!

Reply via email to