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

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

Материал из Википедии

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

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

EDIT:. Это может быть использовано для разрушения всех 4 свойств ACID. Мой первоначальный ответ был неправильным.

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

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

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

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

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

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

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