Насколько ACID является протоколом двухфазной фиксации?

Question

Я столкнулся с ситуацией, когда начал сомневаться, действительно ли протокол двухфазной фиксации гарантирует свойства ACID, особенно его часть 'A'.

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

Теперь небольшое изменение в сценарии. Пока распределенная транзакция выполняет commit (), другое приложение использует те же 2 ресурса. Может ли он видеть только часть изменений от транзакции? Допустим, изменения в одном ресурсе уже видны, в то время как изменения во втором ресурсе еще не видны?

Во всей информации, которую я прочитал по протоколу 2PC, я не смог найти никаких гарантий относительно видимости изменений в отдельных ресурсах относительно друг друга. И я не смог найти ничего, что говорило бы о том, что все ресурсы завершают свои отдельные коммиты в одно и то же время.

Answer 1

Я думаю, что вы путаете темы. 2PC гарантирует, что транзакции совершаются с определенной видимостью. То есть в вашей транзакции данные, которые вы фиксируете, будут упорядочены особым образом, и фиксации с этими транзакциями будут фиксироваться последовательно.

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

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

Answer 2

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

Answer 3

Из Википедии

В статье ранее прямо указывается, что 2PC не устойчив ко всем возможным конфигурациям сбоев .Более конкретная ссылка здесь: Протокол трехфазной фиксации :

3PC был первоначально описан Дейлом Скином и Майклом Стоунбрейкером в их статье «Формальная модель восстановления после сбоя в распределенной системе».»[1].В этой работе они смоделировали 2PC как систему недетерминированных автоматов конечных состояний и доказали, что она не устойчива к случайному отказу одного сайта.

РЕДАКТИРОВАТЬ: Это можетиспользоваться для нарушения всех 4 свойств ACID .Мой первоначальный ответ был неверным.

Видимость изменений

является ортогональной проблемой и зависит от конфигурации участвующих когорт (см. Уровни изоляции ).

Основная часть вашего вопроса и блога о Изоляция , а не Атомность .Атомарность означает, что транзакция всегда заканчивается до конца, в конечном итоге фиксируя все изменения (или откатывая все назад).

Даже если все когорты Serializable и используют тот же TransactionManager, я все еще вижу возможностьчтобы обойти изоляцию, запуская новые транзакции в нужное время.

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

Из личного опыта

Из-за блокирующего характера 2PC является избыточным решением практически в любой практической ситуации, а разумный дизайн мест хранения и потоков данных может датьлучшее решение.По сути, вам нужен уникальный наиболее авторитетный источник любой информации, и все другие вовлеченные стороны должны иметь возможность обновиться до этого авторитетного состояния.http://en.wikipedia.org/wiki/Communicating_sequential_processes - это большое вдохновение, особенно реализованное в Go .Современные распределенные базы данных: BASE вместо ACID (http://en.wikipedia.org/wiki/Eventual_consistency).