Параллелизм и репликация данных

Три проблемы

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

• проблема потери результатов обновления;
• проблема незафиксированной зависимости;
• проблема несовместимого анализа.

Проблема потери результатов обновления

Рассмотрим ситуацию, показанную в таблице 14.1.

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

Проблема незафиксированной зависимости

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

В том случае, когда изменения, сделанные второй транзакцией, сразу становятся видны всем остальным (режим "грязного чтения" - см. ниже), первая транзакция читает "измененные" данные. Проведя вычисления, первая транзакция фиксирует результат. Вторая же транзакция производит откат изменений, т.е. фактически значения баланса, прочитанного первой транзакцией, никогда не существовало! Стоит отметить, что, несмотря на то, что вторая транзакция была отменена, результаты первой транзакции были уже зафиксированы и отменены не будут.

Проблема несовместимого анализа

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

Представим, например, "банковское" приложение, которое подсчитывает сумму средств на счетах всех клиентов банка.

Процедура подсчета идет "сверху вниз" по таблице счетов и суммирует их. Допустим, процедура была запущена в момент времени t1. Далее, в момент времени между t1 и t2 была запущена транзакция, которая состояла из двух действий - снять 100 рублей со счета Иванова и перечислить их на счет Яковлева (к этому моменту процедура суммирования уже учла сумму на счете Иванова, но до Яковлева еще не дошла). Транзакция была очень короткой. После того, как транзакция была успешно завершена, ее результаты стали "видны" первой процедуре. Таким образом, когда она дойдет до записи со счетом Яковлева, ей будет учтена сумма в 500 рублей. В результате сумма счетов в "банке" будет на 100 рублей завышена.

Блокировка

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

Опишем функционирование блокировки более подробно.

1. Прежде всего предположим, что в системе поддерживается два типа блокировок: блокировка без взаимного доступа (монопольная блокировка), называемая Х-блокировкой ( X locks - eXclusive locks ), и блокировка с взаимным доступом,называемая S -блокировкой ( S locks - Shared locks ). (Здесь предполагается, что Х - и S -блокировки - единственно возможные, хотя в реальных системах управления блокировками встречаются блокировки других типов).
2. Если транзакция А блокирует объект р без возможности взаимного доступа (Х-блокировка), то запрос другой транзакции В с блокировкой этого объекта р будет отменен.
3. Если транзакция А блокирует объект р с возможностью взаимного доступа ( S -блокировка), то
   • запрос со стороны некоторой транзакции В на Х -блокировку объекта будет отвергнут;
   • запрос со стороны некоторой транзакции В на S -блокировку объекта р будет принят (т.е. транзакция В также будет блокировать объект р с помощью S -блокировки).

Эти правила можно наглядно представить в виде матрицы совместимости (таблица 14.4) и интерпретировать ее следующим образом.

Рассмотрим некоторый объект р и предположим, что транзакция А блокирует объект р различными типами блокировки. Предположим также, что некоторая транзакция В запрашивает блокировку объекта р, что обозначено в первом слева столбце матрицы. Символ N обозначает конфликтную ситуацию (запрос со стороны транзакции В не может быть удовлетворен, и сама эта транзакция переходит в состояние ожидания), а Y - полную совместимость (запрос со стороны транзакции В удовлетворен). Очевидно, что эта матрица является симметричной.

Теперь следует ввести протокол доступа к данным, который на основе введения только что описанных Х - и S -блокировок позволяет избежать возникновения проблем параллелизма:

1. транзакция, предназначенная для чтения состояния объекта, прежде всего должна наложить S -блокировку на этот кортеж;
2. транзакция, предназначенная для изменения состояния объекта, прежде всего должна наложить Х -блокировку на этот объект. Если для последовательности действий типа "извлечение/обновление" для объекта уже задана S -блокировка, то ее необходимо заменить Х -блокировкой;
3. если запрашиваемая блокировка со стороны транзакции В отвергается из-за конфликта с некоторой другой блокировкой со стороны транзакции А, то транзакция В переходит в состояние ожидания. Причем транзакция В будет находиться в состоянии ожидания до тех пор, пока не будет снята блокировка, заданная транзакцией А ;
4. Х -блокировки сохраняются вплоть до конца выполнения транзакции. S -блокировки также обычно сохраняются вплоть до этого момента.