В данном посте описана система блокировок и поддержания атомарности, согласованности, изолированности и надежности (ACID) в SQLite, а также алгоритмы записи и чтения из файла базы.
Pager Module
Блокировки и параллельный доступ в SQLite версии 3 и выше обрабатывается пейджером (pager module). Данный модуль отвечает за ACID. Пейджер не интересует детали кодировок базы, В – деревьев, индексов и др., с его точки зрения база данных – это один файл, разделенный на равные по размеру блоки (страницы) пронумерованные начиная с 1. Пейджер общается с операционной системой с помощью прослойки OS Interface. В данном посте «поток», «процесс» и «нить» — равносильные понятия.
Блокировки
С точки зрения одного процесса, файл базы данных может находится в одном из 5 состояний блокировки перечисленных ниже:
- UNLOCKED — Состояние по умолчанию. База данных разблокирована, любые потоки могут читать и записывать данные.
- SHARED — База данных доступна для чтения, но не для записи.
- RESERVED — Процесс планирует запись в файл, но в настоящий момент читает. Только одна RESERVED блокировка может быть в один момент времени. Совместно с данным режимом может использоваться SHARED блокировка.
- PENDING — Процесс ожидает окончание всех SHARED блокировок для начала записи и перехода в EXCLUSIVE режим.
- EXCLUSIVE — Процесс производит запись в файл базы. Никакие другие блокировки базы параллельно с данной недопустимы.
Ниже представлены алгоритмы для чтения и записи данных при использовании rollback журнала в качестве гарантии целостности базы.
Алгоритм чтения данных из базы
Для чтения из базы, процесс должен произвести следующие шаги:
- Открыть файл базы и получить SHARED блокировку, если данное действие невозможно вернуть SQLITE_BUSY.
- Проверить имеет ли база горячий журнал отката. Если нет, то можно читать данные из базы. Если да, то шаг 3.
- Получить PENDING, а затем EXCLUSIVE блокировку. Если нет возможности получить данные блокировки, значит, другой процесс уже производит откат. В этом случае снять все блокировки и вернуть SQLITE_BUSY.
- Прочитать журнал отката и мастер журнал (при присоединении нескольких баз, создается специальный файл (master journal), в котором хранится данные о журналах отката для каждой из присоединенных баз).
- Произвести откат
- Удалить файл журнала отката (в зависимости от опции journal_mode команды PRAGMA удаление происходит по-разному).
- Удалить файл мастер журнала, если это возможно.
- Снять PENDING и EXCLUSIVE блокировки, но оставить SHARED блокировку, и произвести чтение базы данных.
Алгоритм записи данных в базу
Для записи данных в базу, процесс сначала должен произвести следующие шаги:
- Получить SHARED блокировку (алгоритм чтения из базы).
- Получить RESERVED блокировку. Если нет такой возможности, вернуть SQLITE_BUSY.
- Создать журнал отката. В заголовке журнала прописывается размер базы данных, а также имя мастер журнала, если такой существует.
- Перед внесением изменений в любой странице базы данных, процесс сначала вносит данную страницу в журнал отката. Измененные страницы в первую очередь записываются в RAM, это значит, что файл базы не изменяется, и другие процессы могут читать данные из базы. Если изменение данных закончилось и процесс производит COMMIT, либо если память переполнилась, перейти к шагу 5.
- Убедиться, что все данные журнала отката были фактически записаны на диск.
- Получить PENDING, а затем EXCLUSIVE блокировку. Если нет возможности получить данные блокировки, необходимо ждать пока файл базы освободиться.
- Записать все данные из RAM на диск в файл базы данных (если причиной записи было переполнение RAM, то вернуться к шагу 4).
- Удалить файл журнала отката (в зависимости от опции journal_mode команды PRAGMA удаление происходит по-разному).
- Снять PENDING и EXCLUSIVE блокировки.
Более подробно алгоритм атомарного коммита рассматривается в другом посте: habrahabr.ru/post/181584/
Автор: rpsv
