Тупиковая ситуация

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

Примечание. Имеется в виду, что приведенные на этом рисунке операции блокировки обозначают любые операции, устанавливающие блокировки, а совсем не обязательно предложения SQL LOCK TABLE.

Рис. 11.10. Пример тупиковой ситуации

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

Если возникает тупиковая ситуация, система обнаруживает и ликвидирует ее. Для того чтобы ликвидировать тупиковую ситуацию, одна из вовлеченных в нее транзакций выбирается в качестве жертвы и, в зависимости от обстановки, либо автоматически производится ее откат, либо от нее требуется произвести откат самостоятельно. Между прочим на этот запрос не может последовать отказа. В любом случае данная транзакция снимет свои блокировки и, таким образом, позволит продолжить исполнение некоторой другой транзакции. Следовательно, в общем случае любая операция, требующая блокировки, в частности любая операция манипулирования данными языка SQL, может быть отвергнута с отрицательным значением SQLCODE, указывающим, что эта транзакция только что была выбрана жертвой в тупиковой ситуации, и либо уже был произведен ее откат, либо требуется его выполнить. Тупиковые ситуации представляют собой, таким образом, важную проблему, когда речь идет о прикладном программисте, поскольку может потребоваться включить в прикладные программы явные средства, имеющие с ними дело, если они возникают. Например:

ЕХЕС SQL...;

IF SQLCODE = значение, указывающее ”жертву тупиковой ситуации”

THEN DO;

ROLLBACK;

повторно инициализировать переменные с помощью

начальных входных данных;

GO TO начало программы;

END;

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

РЕЗЮМЕ

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

В системе DB2, в частности, транзакции ограничиваются точками синхронизации, которые учреждаются при инициации программ, выполнении операций COMMIT (успешное завершение) и ROLLBACK (неудачное завершение).

Примечание. COMMIT и ROLLBACK—это операции, которые используются в обстановке TSO. В обстановке IMS и CICS используются другие, аналогичные операции. Система DB2 гарантирует атомарность таких транзакций, как показано в разделах 11.2 и 11.3.

Управление параллельным исполнением транзакций в DB2 основано на блокировании. По существу, каждая запись, к которой обращается транзакция, подвергается блокировке типа S. Если транзакция собирается обновлять запись, то эта блокировка типа S повышается до уровня блокировки типа X. Блокировки типаX,и обычно также типа S, удерживаются до следующей точки синхронизации. Этот простой протокол решает три основные проблемы управления параллельными транзакциями, но вместе с тем порождает возможность тупиковых ситуаций. Следовательно, прикладные программы должны быть готовы иметь дело с такой возможностью. О возникновении тупиковой ситуации сигнализирует некоторое отрицательное значение SQLCODE, которое потенциально может возвращаться после любой операции языка SQL, требующей блокировки.