2015-07-03
240
| СЧЕТ 1 | СЧЕТ 2 | СЧЕТ 3 | |||||||||
| Транзакция А | Время | Транзакция В | |||||||||
| — | — | ||||||||||
| — | — | ||||||||||
| FETCH СЧЕТ 1 (40): | t1 | — | |||||||||
| (установить блокировку | |||||||||||
| типа S для СЧЕТА 1): | — | ||||||||||
| сумма = 40 | — | ||||||||||
| — | — | ||||||||||
| FETCH СЧЕТ 2 (50): | t2 | — | |||||||||
| (установить блокировку | |||||||||||
| типа S для СЧЕТА 2): | — | ||||||||||
| сумма = 90 | t3 | FETCH СЧЕТ 3 (30) | |||||||||
| — | (установить блокировку | ||||||||||
| — | типа S для СЧЕТА3): | ||||||||||
| — | — | ||||||||||
| — | t4 | UPDATE СЧЕТ 3 | |||||||||
| — | (установить блокировку | ||||||||||
| — | типа Х для СЧЕТА З): | ||||||||||
| — | 30®20 | ||||||||||
| — | |||||||||||
| — | t5 | FETCH СЧЕТ 1 (40) ( | |||||||||
| — | запрос блокировки) | ||||||||||
| — | типа S для СЧЕТА1 | ||||||||||
| — | ждать | ||||||||||
| — | t6 | UPDATE СЧЕТ 1 | |||||||||
| — | (установить блокировку | ||||||||||
| — | типа Х для СЧЕТА 1) | ||||||||||
| FETCH СЧЕТ 3 (20): | t7 | ждать | |||||||||
| (запрос блокировки | ждать | ||||||||||
| S для СЧЕТА З): | ждать | ||||||||||
| Ждать | ждать | ||||||||||
| Ждать | |||||||||||
Рис. 11.9. Исключается анализ на противоречивость, но в момент t6 возникает тупиковая ситуация
|
|
|
Рис. 11.9—это модифицированный вариант рис. 11.4, показывающий, что произошло бы при параллельном исполнении представленных на этом рисунке транзакций под управлением механизма блокирования, который используется в системе DB2. Нетрудно видеть, что запрос транзакции В на операцию UPDATE и момент t6 не принимается, поскольку он является неявным запросом на блокировку типа Х для СЧЕТА 1, а такой запрос вступает в конфликт с блокировкой типа S, уже установленной транзакцией А. Поэтому В переходит в состояние ожидания. Подобным же образом в момент t7 не принимается также запрос транзакции А на выполнение операции FETCH, так как он является неявным запросом на установление блокировки типа S для СЧЕТА 3, а такой запрос вступает в конфликт с блокировкой типа X, уже установленной транзакцией В. По этой причине А также переходит в состояние ожидания. Итак, снова первоначальная проблема (в данном случае, проблема анализа на противоречивость) решается в системе DB2 путем форсирования возникновения тупиковой ситуации. Как уже говорилось, проблема тупиковых ситуаций обсуждается в разделе 11.7.
ВОЗМОЖНОСТИ ЯВНОГО БЛОКИРОВАНИЯ
Помимо механизма неявного блокирования, описанного в предыдущем разделе, система DB2 обеспечивает некоторые явные возможности, о которых программист должен быть по меньшей мере осведомлен, хотя в большинстве ситуаций будет достаточно неявных возможностей. Средства явного блокирования в некоторой мере неоднородны и состоят из 1) предложения LOCK TABLE (блокировать таблицу) языка SQL, 2) факультативного параметра уровня изоляции в команде BIND и 3) параметра «единица блокирования» табличного пространства.
|
|
|
