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 DataStorageConfiguration. Sincerely, 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! >
