Сериализуемость

В управления параллелизмом в базах данных , ^{[1] [2]} обработки транзакций (управление транзакциями), а также различные транзакционные приложения (например, транзакционной памяти ^[3] и программное обеспечение транзакционной памяти ), как централизованное и распределены , сделка расписание является сериализуемымесли его результат (например, результирующее состояние базы данных) равен результату его транзакций, выполняемых последовательно, то есть без перекрытия во времени. Транзакции обычно выполняются одновременно (они перекрываются), поскольку это наиболее эффективный способ. Сериализуемость - главный критерий правильности выполнения параллельных транзакций ^{[ необходима цитата ]} . Он считается наивысшим уровнем изоляции между транзакциями и играет важную роль в управлении параллелизмом . Таким образом, он поддерживается во всех системах баз данных общего назначения. Сильная строгая двухфазная блокировка (SS2PL) - популярный механизм сериализуемости, используемый в большинстве систем баз данных (в различных вариантах) с момента их появления в 1970-х годах.

Теория сериализуемости обеспечивает формальную основу для размышлений и анализа сериализуемости и ее методов. Хотя он носит математический характер, его основы неформально (без математических обозначений) представлены ниже.

Правильность [ править ]

Сериализуемость [ править ]

Сериализуемость используется для сохранения данных в элементе данных в согласованном состоянии. Сериализуемость - это свойство расписания транзакций (истории). Это относится к свойству изоляции транзакции базы данных .

Сериализуемость расписания означает эквивалентность (по результату, состоянию базы данных, значениям данных) последовательному расписанию (т. Е. Последовательному без перекрытия транзакций во времени) с теми же транзакциями. Это основной критерий правильности расписания параллельных транзакций, поэтому он поддерживается во всех системах баз данных общего назначения. ^{[ необходима цитата ]}

Обоснование сериализуемости следующее:

Если каждая транзакция является правильной сама по себе, т. Е. Соответствует определенным условиям целостности, тогда расписание, которое включает любое последовательное выполнение этих транзакций, является правильным (его транзакции по-прежнему соответствуют их условиям): «Последовательный» означает, что транзакции не перекрываются во времени и не могут мешают друг другу, т. е. между собой существует полная изоляция . Любой порядок транзакций является законным, если между ними нет зависимостей, что предполагается (см. Комментарий ниже). В результате расписание, которое включает любое выполнение (не обязательно последовательное), эквивалентное (по своему результату) любому последовательному выполнению этих транзакций, является правильным.

Расписания, которые нельзя сериализовать, могут привести к ошибочным результатам. Хорошо известные примеры - транзакции, которые дебетуют и кредитуют счета деньгами: если связанные расписания не сериализуемы, то общая сумма денег не может быть сохранена. Деньги могут исчезнуть или появиться из ниоткуда. Это и нарушения возможно необходимых других инвариантных сохранений вызваны записью одной транзакции, а также «наступлением» и стиранием того, что было записано другой транзакцией, прежде чем это станет постоянным в базе данных. Этого не происходит, если сохраняется сериализуемость.

Если приложение запрашивает какой-либо конкретный порядок между некоторыми транзакциями, он применяется независимо от базовых механизмов сериализуемости. Эти механизмы обычно безразличны к любому конкретному порядку и генерируют непредсказуемый частичный порядок, который обычно совместим с несколькими последовательными порядками этих транзакций. Этот частичный порядок является результатом планирования операций доступа к данным параллельных транзакций, которые зависят от многих факторов.

Основной характеристикой транзакции базы данных является атомарность , что означает, что она либо фиксируется , то есть результаты всех ее операций вступают в силу в базе данных, либо прерывается (откат), результаты всех ее операций не влияют на база данных (семантика транзакции "все или ничего"). Во всех реальных системах транзакции могут прерваться по многим причинам, и сама по себе сериализуемость недостаточна для корректности. Расписания также должны обладать свойством восстанавливаемости (от прерывания). Восстанавливаемостьозначает, что зафиксированные транзакции не читали данные, записанные прерванными транзакциями (чьи эффекты не существуют в результирующих состояниях базы данных). Хотя сериализуемость в настоящее время специально скомпрометирована во многих приложениях для повышения производительности (только в тех случаях, когда корректность приложения не нарушается), нарушение восстанавливаемости быстро нарушит целостность базы данных, а также результаты транзакций, внешних по отношению к базе данных. График со свойством восстанавливаемости ( восстанавливаемыйschedule) "восстанавливается" после прерывания самостоятельно, т. е. прерывания не нарушают целостность зафиксированных транзакций и результирующей базы данных. Это неверно без возможности восстановления, когда вероятные нарушения целостности (приводящие к неверным данным базы данных) требуют специальных, обычно ручных корректирующих действий в базе данных.

Реализация возможности восстановления в ее общей форме может привести к каскадному прерыванию : прерывание одной транзакции может привести к необходимости прервать вторую транзакцию, затем третью и т. Д. Это приводит к потере уже частично выполненных транзакций и может также привести к снижению производительности. Предотвращение каскадных прерываний (ACA, или безкаскадность) - это особый случай восстанавливаемости, который точно предотвращает такие явления. Часто на практике используется особый случай ACA: строгость . Строгость позволяет эффективно восстанавливать базу данных после сбоя.

Обратите внимание, что свойство восстанавливаемости необходимо, даже если не происходит сбоя базы данных и восстановление базы данных после сбоя не требуется. Скорее, это необходимо для правильной автоматической обработки прерываний, которые могут быть не связаны с отказом базы данных и восстановлением после сбоя.

Расслабляющая сериализуемость [ править ]

Во многих приложениях, в отличие от финансов, абсолютная корректность не нужна. Например, при получении списка продуктов в соответствии со спецификацией в большинстве случаев не имеет большого значения, если продукт, данные которого были обновлены недавно, не отображается в списке, даже если он соответствует спецификации. Обычно он появляется в таком списке при повторной попытке через некоторое время. Коммерческие базы данных обеспечивают контроль параллелизма с целым рядом уровней изоляции, которые на самом деле (контролируемые) нарушения сериализуемости для достижения более высокой производительности. Более высокая производительность означает лучшую скорость выполнения транзакций и более короткое среднее время отклика транзакции (продолжительность транзакции). Изоляция снимковявляется примером популярного, широко используемого эффективного метода расслабленной сериализуемости со многими характеристиками полной сериализуемости, но по-прежнему не хватает некоторых и непригоден во многих ситуациях.

Еще одна распространенная причина , в настоящее время для распределенной сериализуемости релаксации (см ниже) является требование наличия в интернет - продуктов и услуг . На это требование обычно отвечает крупномасштабная репликация данных . Простое решение для синхронизации обновлений реплик одного и того же объекта базы данных - это включение всех этих обновлений в одну атомарную распределенную транзакцию . Однако со многими репликами такая транзакция очень велика и может охватывать несколько компьютеров и сетей.что некоторые из них, вероятно, будут недоступны. Таким образом, такая транзакция, скорее всего, завершится прерыванием и не выполнит свою задачу. ^[4] Следовательно, оптимистическая репликация (ленивая репликация) часто используется (например, во многих продуктах и ​​услугах Google , Amazon , Yahoo и т.п.), в то время как сериализуемость ослаблена и скомпрометирована для обеспечения согласованности в конечном итоге . Опять же, в этом случае релаксация выполняется только для приложений, которые, как ожидается, не пострадают от этой техники.

Классы расписаний, определенные с помощью свойств ослабленной сериализуемости, либо содержат класс сериализуемости, либо несовместимы с ним.

Сериализуемость представлений и конфликтов [ править ]

Механизмы, обеспечивающие сериализуемость, должны выполняться в режиме реального времени или почти в реальном времени, в то время как транзакции выполняются с высокой скоростью. Чтобы удовлетворить это требование, используются особые случаи сериализуемости, достаточные условия сериализуемости, которые могут быть эффективно реализованы.

Существует два основных типа сериализуемости: сериализуемость представления и сериализуемость конфликта . Сериализуемость представления соответствует общему определению сериализуемости, данному выше. Сериализуемость конфликтов - это широкий частный случай, т. Е. Любое расписание, которое сериализуемо по конфликтам, также может сериализоваться по просмотру, но не обязательно наоборот. Конфликт-сериализуемость широко используется, потому что ее легче определить и она охватывает значительную часть сериализуемых представлений расписаний. Определение возможности сериализации представлений расписания - это NP-полная проблема (класс задач, для которых известны только трудные для вычисления и занимающие слишком много времени известные решения).

Возможность сериализации представления расписания определяется эквивалентностью последовательного расписания (без перекрывающихся транзакций) с одними и теми же транзакциями, так что соответствующие транзакции в двух расписаниях читают и записывают одни и те же значения данных («просматривают» одни и те же значения данных).

Сериализуемость конфликтов определяется эквивалентностью последовательного расписания (без перекрывающихся транзакций) с одними и теми же транзакциями, так что оба расписания имеют одинаковые наборы соответствующих хронологически упорядоченных пар конфликтующих операций (одинаковые отношения приоритета соответствующих конфликтующих операций).

Операции над данными чтения или записи (а запись: либо вставить или изменить или удалить ). Две операции конфликтуют, если они относятся к разным транзакциям с одним и тем же элементом данных (элементом данных), и хотя бы одна из них является записью . Каждая такая пара конфликтующих операций имеет тип конфликта : это конфликт чтения-записи , или записи-чтения , или конфликт записи-записи . Транзакция второй операции в паре считается конфликтной.при сделке первой операции. Более общее определение конфликтующих операций (также для сложных операций, каждая из которых может состоять из нескольких «простых» операций чтения / записи) требует, чтобы они были некоммутативными (изменение их порядка также изменяет их объединенный результат). Каждая такая операция должна быть атомарной сама по себе (с использованием надлежащей системной поддержки), чтобы считаться операцией для проверки коммутативности. Например, операции чтения-чтения являются коммутативными (в отличие от чтения-записи и других возможностей), и поэтому чтение-чтение не является конфликтом. Еще более сложный пример: операции инкремент и декремент из счетчика оба записиоперации (оба изменяют счетчик), но их не следует рассматривать как конфликтующие (тип конфликта записи-записи), поскольку они являются коммутативными (таким образом, инкремент-декремент не является конфликтом; например, он уже поддерживался в старой IMS IBM "fast путь"). Только приоритет (временной порядок) в парах конфликтующих (некоммутативных) операций важен при проверке эквивалентности последовательному расписанию, поскольку разные расписания, состоящие из одних и тех же транзакций, могут быть преобразованы из одного в другой, изменяя порядок между операциями разных транзакций ( чередование различных транзакций), и поскольку изменение порядка коммутативных операций (неконфликтных) не меняет общий результат последовательности операций, то есть результат расписания (результат сохраняется за счет изменения порядка между неконфликтными операциями, но обычно не когда порядок изменения конфликтующих операций). Это означает, что если расписание может быть преобразовано в любое серийное расписание без изменения порядка конфликтующих операций (но изменения порядков неконфликтных,при сохранении порядка операций внутри каждой транзакции), то результат обоих расписаний будет одинаковым, и расписание по определению является конфликтно-сериализуемым.

Конфликты являются причиной блокировки транзакций и задержек (нематериализованные конфликты) или прерывания транзакций из-за предотвращения нарушения сериализуемости. Обе возможности снижают производительность. Таким образом, уменьшение количества конфликтов, например, за счет коммутативности (когда это возможно), является способом повышения производительности.

Транзакция может выдавать / запрашивать конфликтующую операцию и конфликтовать с другой транзакцией, в то время как ее конфликтующая операция задерживается и не выполняется (например, блокируется блокировкой ). Только выполненные ( материализованные ) конфликтующие операции имеют отношение к сериализуемости конфликтов (подробнее см. Ниже).

Обеспечение сериализации конфликтов [ править ]

Тестирование сериализуемости конфликтов [ править ]

График соответствие сериализуемости конфликта может быть протестировано с очередностью графом ( сериализуемости графа , сериализациями графа , конфликт граф ) за совершенные сделки по расписанию. Это ориентированный граф, представляющий приоритет транзакций в расписании, что отражается в приоритете конфликтующих операций в транзакциях.

В графе приоритета транзакции являются узлами, а отношения предшествования - направленными ребрами. Существует преимущество от первой транзакции до второй транзакции, если вторая транзакция конфликтует с первой (см. Сериализуемость конфликтов выше), и конфликт материализуется (т. Е. Если запрошенная конфликтующая операция действительно выполняется: во многих случаях запрошенная / выпущенная конфликтующая операция транзакцией откладывается и даже никогда не выполняется, как правило, из-за блокировкина объекте операции, удерживаемом другой транзакцией, или при записи во временную частную рабочую область транзакции и материализации, копировании в саму базу данных при фиксации; до тех пор, пока запрошенная / выданная конфликтующая операция не выполняется в самой базе данных, конфликт не материализуется ; нематериализованные конфликты не представлены ребром в графе приоритета).

Комментарий: Во многих учебниках только подтвержденные транзакции включаются в граф приоритета. Здесь все транзакции включены для удобства в последующих обсуждениях.

Следующее наблюдение является ключевой характеристикой сериализуемости конфликтов :

Расписание является конфликтно-сериализуемым тогда и только тогда, когда его граф приоритета зафиксированных транзакций (когда учитываются только подтвержденные транзакции) является ациклическим . Это означает, что цикл, состоящий только из зафиксированных транзакций, генерируется в (общем) графе приоритета тогда и только тогда, когда нарушается конфликт-сериализуемость.

Циклы зафиксированных транзакций можно предотвратить, прервав нерешенную (ни зафиксированную, ни прерванную) транзакцию в каждом цикле в графе приоритета всех транзакций, который в противном случае может превратиться в цикл зафиксированных транзакций (и зафиксированная транзакция не может быть прервана) . Одна транзакция, прерванная за цикл, и требуется, и ее достаточно, чтобы прервать и исключить цикл (возможны и другие прерывания, которые могут произойти при некоторых механизмах, но не нужны для сериализуемости). Вероятность генерации цикла обычно невелика, но, тем не менее, такая ситуация тщательно обрабатывается, как правило, со значительными накладными расходами, поскольку требуется корректность. Транзакции, прерванные из-за предотвращения нарушения сериализуемости, перезапускаются и немедленно выполнен снова.

Механизмы обеспечения сериализуемости обычно не поддерживают граф приоритета как структуру данных, а скорее неявно предотвращают или прерывают циклы (например, SS2PL ниже).

Общий механизм - SS2PL [ править ]

Сильная строгая двухфазная блокировка (SS2PL) - распространенный механизм, используемый в системах баз данных с первых дней их существования в 1970-х годах (хотя «SS» в имени SS2PL новее) для обеспечения как сериализуемости конфликтов, так и строгости (особый случай восстанавливаемость, которая позволяет эффективно восстанавливать базу данных после сбоя) по расписанию. В соответствии с этим механизмом каждая база данных блокируется транзакцией до того, как она получит к ней доступ (в любой операции чтения или записи): элемент отмечен и связан с блокировкойопределенного типа в зависимости от выполняемой операции (и конкретной реализации транзакции; существуют различные модели с разными типами блокировки; в некоторых моделях блокировки могут изменять тип в течение жизни транзакции). В результате доступ другой транзакции может быть заблокирован, как правило, при конфликте (блокировка задерживает или полностью предотвращает материализацию конфликта и отражается в графе приоритета, блокируя конфликтующую операцию), в зависимости от типа блокировки и другой транзакции. тип операции доступа. Использование механизма SS2PL означает, что все блокировки данных от имени транзакции снимаются только после того, как транзакция завершилась (либо зафиксирована, либо прервана).

SS2PL - это также имя результирующего свойства расписания, которое также называется строгостью . SS2PL - это частный случай ( собственное подмножество ) двухфазной блокировки (2PL).

Взаимная блокировка между транзакциями приводит к тупиковой ситуации , когда выполнение этих транзакций останавливается и завершение невозможно. Таким образом, тупиковые ситуации необходимо разрешить, чтобы завершить выполнение этих транзакций и освободить связанные вычислительные ресурсы. Тупиковая ситуация - это отражение потенциального цикла в графе приоритета, который произошел бы без блокировки при материализации конфликтов. Тупиковая ситуация разрешается путем прерывания транзакции, связанной с таким потенциальным циклом, и разрыва цикла. Это часто обнаруживается с помощью графика ожидания.(граф конфликтов, заблокированных блокировками от материализации; его также можно определить как граф нематериализованных конфликтов; не материализованные конфликты не отражаются в графе приоритета и не влияют на сериализуемость), который указывает, какая транзакция находится в состоянии ожидания. для "снятия одной или нескольких блокировок, посредством которых другая транзакция или транзакции, и цикл в этом графе означает тупик". Прервать одну транзакцию за цикл достаточно, чтобы разорвать цикл. Транзакции, прерванные из-за разрешения тупиковых ситуаций, перезапускаются и немедленно выполняются снова.

Другие методы принуждения [ править ]

Другие известные механизмы включают:

• Исключение цикла графа приоритета (или графа сериализуемости, графа конфликтов)
• Двухфазная блокировка (2PL)
• Упорядочивание меток времени (TO)
• Изоляция сериализуемых снимков ^[5] (SerializableSI)

Вышеупомянутые (конфликтные) методы сериализуемости в их общей форме не обеспечивают возможности восстановления. Для повышения восстанавливаемости необходимы специальные улучшения.

Оптимистические и пессимистические методы [ править ]

Техники управления параллелизмом бывают трех основных типов:

1. Пессимистичный : при пессимистическом управлении параллелизмом транзакция блокирует операции доступа к данным других транзакций при конфликтах, и конфликты не материализуются, пока блокировка не будет снята. Это сделано для того, чтобы гарантировать, что операции, которые могут нарушить сериализуемость (а на практике также восстанавливаемость), не выполняются.
2. Оптимистичный : при оптимистичном управлении параллелизмом операции доступа к данным других транзакций не блокируются при конфликтах, и конфликты немедленно материализуются . Когда транзакция достигает состояния готовности , т. Е. Ее рабочее состояние завершено, проверяется возможное нарушение сериализуемости (а на практике также восстанавливаемости) операциями транзакции (по сравнению с другими выполняющимися транзакциями): если нарушение произошло, транзакция обычно прервано (иногда предпочтительно прерывание другой транзакции для обработки нарушения сериализуемости). В противном случае совершается .
3. Полуоптимистичный : механизмы, которые сочетают блокировку в определенных ситуациях с отказом от блокировки в других ситуациях и используют как материализованные, так и нематериализованные конфликты.

Основное различие между типами техники - это типы конфликтов, которые они порождают. Пессимистический метод блокирует операцию транзакции при конфликте и генерирует нематериализованный конфликт, тогда как оптимистический метод не блокирует и генерирует материализованный конфликт. Полуоптимистический метод порождает оба типа конфликтов. Оба типа конфликта генерируются хронологическим порядком, в котором вызываются операции транзакции, независимо от типа конфликта. Цикл зафиксированных транзакций (с материализованными конфликтами) в графе приоритета (графе конфликтов) представляет собой нарушение сериализуемости, и его следует избегать для поддержания сериализуемости. Цикл (нематериализованных) конфликтов в графе ожиданияпредставляет собой тупиковую ситуацию, которую следует разрешить, разорвав цикл. Оба типа цикла являются результатом конфликтов и должны быть прерваны. При любом типе техники конфликты следует обнаруживать и учитывать с аналогичными накладными расходами как для материализованных, так и для нематериализованных конфликтов (обычно с использованием таких механизмов, как блокировка, при этом либо блокировка для блокировок, либо не блокировка, а запись конфликта для материализованных конфликтов). В методе блокировки обычно используется переключение контекста.возникает при конфликте с (дополнительными) накладными расходами. В противном случае вычислительные ресурсы, связанные с заблокированными транзакциями, остаются простаивающими, неиспользованными, что может быть худшей альтернативой. Когда конфликты возникают не часто, оптимистические методы обычно имеют преимущество. При разных нагрузках транзакций (смешениях типов транзакций) один тип техники (т. Е. Оптимистичный или пессимистический) может обеспечить лучшую производительность, чем другой.

Если классы расписания не являются блокирующими по своей сути (т. Е. Они не могут быть реализованы без блокировки операций доступа к данным; например, 2PL, SS2PL и SCO выше; см. Диаграмму), они также могут быть реализованы с использованием оптимистических методов (например, сериализуемость, возможность восстановления).

Сериализуемый мультиверсионный контроль параллелизма [ править ]

Смотрите также многовариантность управления параллелизмом (частичное покрытие) и Изоляция Сериализуемый Снимок в изоляции моментальных снимков

Управление многоверсионным параллелизмом (MVCC) - это распространенный сегодня способ повысить параллелизм и производительность путем создания новой версии объекта базы данных каждый раз, когда объект записывается, и разрешения операций чтения транзакций нескольких последних соответствующих версий (каждого объекта), в зависимости от метода планирования. MVCC можно комбинировать со всеми перечисленными выше методами сериализуемости (за исключением SerializableSI, который изначально основан на MVCC). Он используется в большинстве СУБД общего назначения.

MVCC особенно популярен в настоящее время благодаря методу ослабленной сериализуемости (см. Выше). Изоляция моментальных снимков (SI), который обеспечивает лучшую производительность, чем большинство известных механизмов сериализуемости (за счет возможного нарушения сериализуемости в некоторых случаях). SerializableSI , который является эффективным усовершенствованием SI, чтобы сделать его сериализуемым, призван обеспечить эффективное сериализуемое решение. SerializableSI был проанализирован ^{[5] [6] с} помощью общей теории MVCC.

Распределенная сериализуемость [ править ]

Обзор [ править ]

Распределенная сериализуемость - это сериализуемость расписания транзакционной распределенной системы (например, распределенной системы баз данных ). Такая система характеризуются распределенными транзакциями (также называемых глобальными транзакциями ), то есть операции , которые оболочка компьютер обрабатывает (процесс абстракция в общем смысле, в зависимости от вычислительной среды; например, операционная системы «с резьбой ) и , возможно , сетевыми узлами. Распределенная транзакция включает более одной из нескольких локальных суб-транзакций , каждая из которых имеет состояния, как описано выше для транзакции базы данных.. Локальная суб-транзакция состоит из одного процесса или нескольких процессов, которые обычно терпят неудачу вместе (например, в одном ядре процессора ). Распределенные транзакции подразумевают необходимость в протоколе атомарной фиксации для достижения консенсуса среди своих локальных суб-транзакций относительно того, следует ли выполнять фиксацию или прервать. Такие протоколы могут варьироваться от простого (однофазного) установления связи между процессами, которые не работают вместе, до более сложных протоколов, таких как двухфазная фиксация , для обработки более сложных случаев отказа (например, сбой процесса, узла, связи и т. Д.). Распределенная сериализуемость - основная цель контроля корректности распределенного параллелизма . С распространением в сети Интернет , облачные вычисления ,grid-вычислений и небольших портативных мощных вычислительных устройств (например, смартфонов ) потребность в эффективных методах распределенной сериализуемости для обеспечения корректности в распределенных приложениях и между ними, по-видимому, возрастает.

Распределенная сериализуемость достигается за счет реализации распределенных версий известных централизованных методов. ^{[1] [2]}Как правило, все такие распределенные версии требуют использования информации о конфликте (материализованных или нематериализованных конфликтов или, что то же самое, о приоритете транзакции или информации о блокировании; обычно используется сериализуемость конфликтов), которая генерируется не локально, а скорее в разных процессах, и удаленно. локации. Таким образом, необходимо распространение информации (например, отношения приоритета, информация о блокировках, временные метки или билеты). Когда распределенная система имеет относительно небольшой масштаб и задержки сообщений в системе невелики, методы централизованного управления параллелизмом можно использовать без изменений, в то время как определенные процессы или узлы в системе управляют соответствующими алгоритмами. Однако в крупномасштабной системе (например, сетке и облаке), из-за распространения такой информации обычно возникает значительное снижение производительности, даже когда используются распределенные версии методов (по сравнению с централизованными), в первую очередь из-за задержки компьютера и связи . Кроме того, когда такая информация распространяется, связанные методы обычно плохо масштабируются. Хорошо известным примером проблемы масштабируемости является распределенный диспетчер блокировок , который распределяет информацию о блокировках (нематериализованных конфликтах) по распределенной системе для реализации методов блокировки.

См. Также [ править ]

• Сильная строгая двухфазная блокировка (SS2PL или Жесткость).
• Делаем изоляцию снимков сериализуемой ^[5] в изоляции снимков .
• Глобальная сериализуемость , где описывается проблема глобальной сериализуемости и ее предлагаемые решения.
• Линеаризуемость , более общая концепция параллельных вычислений

Заметки [ править ]

Ссылки [ править ]

Эта статья включает в себя список общих ссылок , но он остается в значительной степени непроверенным, поскольку в нем отсутствует достаточное количество соответствующих встроенных ссылок . Пожалуйста, помогите улучшить эту статью, добавив более точные цитаты. ( Ноябрь 2011 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения )

• Филип А. Бернштейн , Вассос Хадзилакос, Натан Гудман (1987): Контроль параллелизма и восстановление в системах баз данных , издательство Addison Wesley Publishing Company, ISBN 0-201-10715-5 
• Герхард Вейкум , Готфрид Фоссен (2001): транзакционные информационные системы , Elsevier, ISBN 1-55860-508-8