ACID в SQLite

В данном посте описана система блокировок и поддержания атомарности, согласованности, изолированности и надежности (ACID) в SQLite, а также алгоритмы записи и чтения из файла базы.

Pager Module

Блокировки и параллельный доступ в SQLite версии 3 и выше обрабатывается пейджером (pager module). Данный модуль отвечает за ACID. Пейджер не интересует детали кодировок базы, В – деревьев, индексов и др., с его точки зрения база данных – это один файл, разделенный на равные по размеру блоки (страницы) пронумерованные начиная с 1. Пейджер общается с операционной системой с помощью прослойки OS Interface. В данном посте «поток», «процесс» и «нить» — равносильные понятия.

Блокировки

С точки зрения одного процесса, файл базы данных может находится в одном из 5 состояний блокировки перечисленных ниже:

• UNLOCKED — Состояние по умолчанию. База данных разблокирована, любые потоки могут читать и записывать данные.
• SHARED — База данных доступна для чтения, но не для записи.
• RESERVED — Процесс планирует запись в файл, но в настоящий момент читает. Только одна RESERVED блокировка может быть в один момент времени. Совместно с данным режимом может использоваться SHARED блокировка.
• PENDING — Процесс ожидает окончание всех SHARED блокировок для начала записи и перехода в EXCLUSIVE режим.
• EXCLUSIVE — Процесс производит запись в файл базы. Никакие другие блокировки базы параллельно с данной недопустимы.

Ниже представлены алгоритмы для чтения и записи данных при использовании rollback журнала в качестве гарантии целостности базы.

Алгоритм чтения данных из базы

Для чтения из базы, процесс должен произвести следующие шаги:

1. Открыть файл базы и получить SHARED блокировку, если данное действие невозможно вернуть SQLITE_BUSY.
2. Проверить имеет ли база горячий журнал отката. Если нет, то можно читать данные из базы. Если да, то шаг 3.
3. Получить PENDING, а затем EXCLUSIVE блокировку. Если нет возможности получить данные блокировки, значит, другой процесс уже производит откат. В этом случае снять все блокировки и вернуть SQLITE_BUSY.
4. Прочитать журнал отката и мастер журнал (при присоединении нескольких баз, создается специальный файл (master journal), в котором хранится данные о журналах отката для каждой из присоединенных баз).
5. Произвести откат
6. Удалить файл журнала отката (в зависимости от опции journal_mode команды PRAGMA удаление происходит по-разному).
7. Удалить файл мастер журнала, если это возможно.
8. Снять PENDING и EXCLUSIVE блокировки, но оставить SHARED блокировку, и произвести чтение базы данных.

Алгоритм записи данных в базу

Для записи данных в базу, процесс сначала должен произвести следующие шаги:

1. Получить SHARED блокировку (алгоритм чтения из базы).
2. Получить RESERVED блокировку. Если нет такой возможности, вернуть SQLITE_BUSY.
3. Создать журнал отката. В заголовке журнала прописывается размер базы данных, а также имя мастер журнала, если такой существует.
4. Перед внесением изменений в любой странице базы данных, процесс сначала вносит данную страницу в журнал отката. Измененные страницы в первую очередь записываются в RAM, это значит, что файл базы не изменяется, и другие процессы могут читать данные из базы. Если изменение данных закончилось и процесс производит COMMIT, либо если память переполнилась, перейти к шагу 5.
5. Убедиться, что все данные журнала отката были фактически записаны на диск.
6. Получить PENDING, а затем EXCLUSIVE блокировку. Если нет возможности получить данные блокировки, необходимо ждать пока файл базы освободиться.
7. Записать все данные из RAM на диск в файл базы данных (если причиной записи было переполнение RAM, то вернуться к шагу 4).
8. Удалить файл журнала отката (в зависимости от опции journal_mode команды PRAGMA удаление происходит по-разному).
9. Снять PENDING и EXCLUSIVE блокировки.

Более подробно алгоритм атомарного коммита рассматривается в другом посте: habrahabr.ru/post/181584