2015-07-03
301
Рис. 11.6 представляет собой модифицированный вариант рис. 11.1, показывающий, что произошло бы при параллельном" исполнении приведенных на рисунке транзакций под управлением механизма блокирования, предусмотренного в системе DB2.
| Транзакция А | Время | Транзакция В | ||
| — | — | |||
| — | — | |||
| FETCH R | t1 | — | ||
| (установить блокировку | — | |||
| типа S для R) | — | |||
| — | t2 | FETCH R | ||
| — | (установить блокировку | |||
| — | типа S для R) | |||
| — | — | |||
| UPDATE R | t3 | — | ||
| (запрос блокировки | — | |||
| типа Х для R) | — | |||
| ждать | t4 | UPDATE R | ||
| ждать | (запрос блокировки | |||
| ждать | типа Х для R) | |||
| ждать | ждать | |||
| ждать | ждать | |||
| ждать | ждать | |||
Рис. 11.6. Не утрачиваются никакие обновления, но в момент t4 возникает тупиковая ситуация
Легко видеть, что запрос транзакции А в момент t3 на операцию UPDATЕ не принимается, поскольку это неявный запрос на блокировку типа Х для записи R, и такой запрос противоречит блокировке типа S, уже установленной транзакцией В. Поэтому А переходит в состояние ожидания. По аналогичным причинам транзакция В переходит в состояние ожидания в момент t4. Теперь обе транзакции не могут быть продолжены. Поэтому не возникает вопрос о том, что какое-либо обновление может быть утрачено. Таким образом, в системе DB2 проблема утраченного обновления решается путем сведения ее к другой проблеме, но это, по крайней мере, действительно решает первоначальную проблему! Эта новая проблема называется проблемой тупиковых ситуаций. Решение этой проблемы в системе DB2 обсуждается в разделе 11.7.
|
|
|
