[Перевод] 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 журнала в качестве гарантии целостности базы.
Алгоритм чтения данных из базы Для чтения из базы, процесс должен произвести следующие шаги: Открыть файл базы и получить 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/
