"Большие" записи (р-р которых больше р-ра страницы) размещают свой
хвост
на отдельных выделенных страницах данных (DP), а начало записи помещается
как
обычная запись на нормальную DP. Выделенные под хвост DP не учитываются на
PP
т.к. их всё равно не возможно адресовать, не трогая начало записи.
Т.е. если запись имеет размер N*P + M, где P - page size, то её хвост
будет размещён
на N выделенных страницах и начало, размером M, будет помещено на общую
DP.
Ну да.
Я к тому что если начать размазывать запись на фрагменты по существующим
(нормальным/зарегистрированным на PP) DP, то будет период существования
"недоделанных" записей.
То есть
1. Блокируем DP_1. пишем кусок на DP_1. Разблокируем DP_1
2. Блокируем DP_2.пишем кусок на DP_2. Разблокируем DP_2
...
N. Блокируем DP_N.пишем кусок на DP_N. Разблокируем DP_N
Если в процессе кто-то начнет читать/анализировать эти DP_x страницы, то он
обнаружит недоделаную запись. Кто именно - я ахез.
А текущая стратегия номер #2 гарантирует что "недоделанные" (хвостовые)
куски появлятся не будут. И параллельно работающие алгоритмы не будут
впадать в ступор, если вдруг начнут лезть к этим недоделанным кускам.
Нет. На DP записывается её собственный логический (последовательный)
номер
(см. Ods::data_page::dpg_sequence). Он используется, например, для
валидации.
Ну и для разборов полётов тоже, есс-но.
Ну да... Но что бы потом перейти к родительской PP, надо
- либо перебирать список PP
- либо юзать и поддерживать в актуальном состоянии in-memory копию этого
списка (оформленную в виде массива). Это у вас так сделано.
А так - прочитали на DP номер родительской PP и все прыгаем на неё без
всяких заморочек.
Коваленко Дмитрий.
