<<
>>

Ожидания и тупики

При использовании блокировки приходится сталкиваться с такими нежелательными явлениями, как бесконечные ожидания и тупиковые ситуации. Бесконечные ожидания могут при определенных условиях появиться в любой системе с параллельным выполнением процессов.
Например, элемент X заблокирован выполняющейся транзакцией Л. Поступившая в систему транзакция Г2, которой также необходима работа с этим элементом, переходит в состояние ожидания. В момент разблокировки элемента X транзакцией Л в систему поступает транзакция Г2, которой также требуется этот элемент, и перехватывает инициативу по его блокировке и т.д. В таких условиях не исключена возможность, что транзакция Т2 будет все время находится в состоянии ожидания.

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

Тупиковые ситуации возникают при параллельном выполнении процессов с использованием блокировок.

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

Существуют следующие подходы к разрешению тупиковых ситуаций.

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

2. Вводится системное требование, чтобы в каждой программе все требуемые блокировки запрашивались сразу. В таком варианте каждая транзакция единовременно запрашивает все необходимые ей блокировки. Это позволяет СУБД управлять транзакциями без тупиковых ситуаций.

3. Никаких системных требований на написание программ не вводится. В этом случае СУБД при функционировании АС следит за возникновением тупиковых ситуаций. При обнаружении тупика действие одной из транзакций аннулируется, все выполненные ею изменения в БД устраняются. Транзакция либо переводится в состояние ожидания, а затем через некоторое время выполняется ее рестарт, либо полностью аннулируется.

Для того чтобы выполнить рестарт или аннулирование транзакции, СУБД выполняет фиксацию транзакций в системном журнале, в котором для каждой транзакции записываются ее идентификатор, все произведенные ею изменения в БД, копия результатов ее вычислений, время начала и завершения. Такая информация позволит в случае системного сбоя выполнить также рестарт всех зафиксированных транзакций, которые не успели успешно завершиться.

<< | >>
Источник: Григорьев Ю.А., Ревунков Г.И.. Банки данных. 2002

Еще по теме Ожидания и тупики:

  1. 1. "Тупик"
  2. Прием преодоления умственных тупиков.
  3. Прием преодоления умственных тупиков.
  4. Тактика при «тупике» переговоров.
  5. СТРЕМЛЕНИЕ ВСЕМ УГОЖДАТЬ – ЭТО ПСИХОЛОГИЧЕСКИЙ ТУПИК
  6. Глава 2 Как психология зашла в тупик, а я из него выбрался
  7. «Висящая» проблема угнетает. Стресс. Как выйти из тупика?
  8. «Висящая» проблема угнетает. Стресс. Как выйти из тупика?
  9. ТРЕВОГА ОЖИДАНИЯ
  10. ПОЧЕМУ ДЕЙСТВУЮТ ПОЗИТИВНЫЕ ОЖИДАНИЯ
  11. Умение различать эти динамики весьма полезно для преодоления таких тупиков.
  12. ЗАКОН ОЖИДАНИЯ
  13. НЕЧУВСТВИТЕЛЬНОСТЬ К ОЖИДАНИЯМ
  14. ОЖИДАНИЕ - ЭТО ЛОВУШКА