"Kovalenko Dmitry" ...
"Большие" записи (р-р которых больше р-ра страницы) размещают свой хвост
на отдельных выделенных страницах данных (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 копию этого списка (оформленную в виде массива). Это у вас так
сделано.
Список PP живёт в RDB$PAGES и дополнительно кеширован в памяти
А так - прочитали на DP номер родительской PP и все прыгаем на неё без всяких
заморочек.
А в чём заморочка ? Или всё, что тебе не понятно - уничтожить ? :-D
--
Хорсун Влад
