ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 31.03.2021
Просмотров: 1570
Скачиваний: 23
176
переходит
в
состояние
ожидания
,
до
тех
пор
пока
объект
Р
не
будет
освобожден
транзакцией
А
.
В
результате
обе
транзакции
находятся
в
состоянии
ожидания
друг
друга
и
не
могут
продолжаться
и
тем
более
завершиться
.
Возникла
ситуация
,
называемая
тупиком
(dead lock).
Проблема
незафиксированной
зависимости
(
чтение
«
грязных
»
данных
,
неаккуратное
считывание
)
Транзакция
В
изменяет
данные
в
строке
.
После
этого
транзакция
А
читает
измененные
данные
и
работает
с
ними
.
Транзакция
В
откатывается
и
восстанавливает
старые
данные
.
Транзакция
А
Время
Транзакция
В
↓
---
t
1
Блокирует
кортеж
P
S
-
блокировкой
↓
---
t
2
Чтение
значения
Р
0
из
кортежа
P
↓
---
t
3
↓
Блокирует
кортеж
P
X
-
блокировкой
(
разрешена
)
---
t
4
Запись
значения
Р
1
в
кортеж
P
↓
t
5
---
Попытка
S
-
блокировки
кортежа
Р
для
его
обновления
отвергается
↓
Ожидание
…
t
6
↓
Откат
транзакции
,
т
.
е
.
восстановление
значения
Р
0
кортежа
P
(
Блокировка
объекта
снимается
)
Блокирует
кортеж
P
S
-
блокировкой
(
теперь
разрешена
)
t
7
↓
---
Чтение
значения
Р
0
из
кортежа
P
t
8
---
↓
t
9
Работа
с
прочитанными
данными
Р
0
↓
---
---
t
10
---
↓
Фиксация
транзакции
t
11
---
↓
Все
правильно
Результат
.
Работа
транзакции
А
была
приостановлена
до
окончания
(
отката
)
транзакции
В
.
После
этого
транзакция
А
продолжила
работу
В
обычном
режиме
и
работала
с
правильными
данными
.
Конфликт
разрешен
за
счет
177
некоторого
увеличения
времени
работы
транзакции
А
(
потрачено
время
на
ожидание
снятия
блокировки
транзакцией
В
).
Проблема
несовместимого
анализа
.
Неповторяемое
считывание
Транзакция
А
дважды
читает
одну
и
ту
же
строку
.
Между
этими
чтениями
вклинивается
транзакция
В
,
которая
изменяет
значения
в
строке
.
Транзакция
А
Время
Транзакция
В
↓
Блокирует
кортеж
P
S
-
блокировкой
t
1
---
↓
Чтение
значения
Р
0
из
кортежа
P
t
2
---
↓
---
t
3
↓
Попытка
X
-
блокировки
кортежа
P
отвергается
---
t
4
Ожидание
…
↓
t
5
Ожидание
…
Повторное
чтение
значения
Р
0
из
кортежа
P
↓
t
6
Фиксация
транзакции
(
Блокировка
объекта
снимается
)
↓
Ожидание
…
---
t
7
↓
Блокирует
кортеж
P
X
-
блокировкой
(
теперь
она
разрешена
)
---
t
8
Запись
значения
Р
1
в
кортеж
P
↓
---
t
9
↓
Фиксация
транзакции
и
снятие
блокировки
↓
Все
правильно
Результат
.
Работа
транзакции
В
приостановилась
до
окончания
транзакции
А
.
В
результате
транзакция
А
дважды
корректно
читает
одни
и
те
же
данные
.
После
окончания
транзакции
А
,
транзакция
В
продолжила
работу
в
обычном
режиме
.
178
Фиктивные
элементы
(
фантомы
)
Транзакция
А
дважды
выполняет
выборку
строк
с
одним
и
тем
же
условием
.
Между
выборками
вклинивается
транзакция
В
,
которая
добавляет
новую
строку
,
удовлетворяющую
условию
отбора
.
Транзакция
А
Время
Транзакция
В
↓
t
1
---
↓
Блокирует
S
-
блокировкой
кортежи
,
удовлетворяющие
условию
α
(
заблокировано
n
строк
)
↓
t
2
---
Выборка
кортежей
,
удовлетворяющих
условию
α
(
выбрано
n
строк
)
↓
---
t
3
↓
Вставка
нового
кортежа
,
удовлетворяющего
условию
α
---
t
4
Фиксация
транзакции
↓
t
5
---
↓
Блокирует
S
-
блокировкой
кортежи
,
удовлетворяющие
условию
α
(
заблокировано
n+1
строка
)
↓
t
6
Выборка
кортежей
,
удовлетворяющих
условию
α
(
выбрано
n+1
строк
)
↓
---
t
7
Фиксация
транзакции
и
снятие
блокировок
↓
---
↓
Появились
кортежи
,
которых
раньше
не
было
Результат
.
Блокировка
на
уровне
строк
не
решила
проблему
появления
фиктивных
элементов
.
179
Собственно
несовместимый
анализ
Длинная
транзакция
выполняет
некоторый
анализ
по
всей
таблице
,
например
,
подсчитывает
общую
сумму
денег
на
счетах
клиентов
банка
для
главного
бухгалтера
.
Пусть
на
всех
счетах
находятся
одинаковые
суммы
,
например
,
по
100
руб
.
Короткая
транзакция
в
этот
момент
выполняет
перевод
50
руб
.
с
одного
счета
на
другой
так
,
что
общая
сумма
по
всем
счетам
не
меняется
.
Транзакция
А
Время
Транзакция
В
↓
Блокирует
счет
Р
1
S
-
блокировкой
t
1
---
↓
t
2
---
Чтение
счета
Р
1
=100
и
суммирование
.
SUM
=100
↓
---
t
3
↓
Блокирует
счет
Р
3
X
-
блокировкой
(
разрешено
)
---
t
4
↓
Снятие
денег
со
счета
Р
3
.
(
на
счете
Р
3
вместо
100
уже
50)
t
5
---
↓
Попытка
X
-
блокировки
счета
Р
1
для
его
обновления
отвергается
t
6
---
↓
Ожидание
t
7
---
↓
Ожидание
…
t
8
Ожидание
…
Чтение
счета
Р
2
=100
и
суммирование
.
SUM
=200
↓
t
9
Попытка
S
-
блокировки
счета
Р
1
для
его
чтения
отвергается
↓
Ожидание
…
Ожидание
…
t
10
Ожидание
…
Ожидание
…
↓
Ожидание
…
Результат
.
Обе
транзакции
ожидают
друг
друга
и
не
могут
продолжаться
.
Опять
возникла
ситуация
тупика
.
Выводы
.
Таким
образом
,
использование
протокола
доступа
к
данным
с
использованием
блокировок
в
рассмотренных
выше
ситуациях
конфликтов
транзакций
,
позволило
получить
следующие
результаты
.
•
Проблема
потери
результатов
обновления
–
возник
тупик
.
•
Проблема
незафиксированной
зависимости
(
чтение
«
грязных
»
данных
) –
проблема
разрешилась
.
180
•
•
•
проблем
Неповторяемое
считывание
–
проблема
разрешилась
.
Появление
фиктивных
элементов
–
проблема
не
разрешилась
.
Проблема
несовместимого
анализа
–
возник
тупик
.
Видно
,
что
использование
блокировок
позволило
часть
из
приведенных
решить
.
Однако
возникла
новая
проблема
–
тупики
.
Общий
вид
тупика
.
Транзакция
А
Время
Транзакция
В
↓
Успешная
блокировка
объекта
Р
1
t
1
---
↓
t
2
Успешная
блокировка
объекта
Р
2
---
↓
t
3
Попытка
блокировки
объекта
Р
2
отвергается
из
-
за
блокировки
,
наложенной
транзакцией
B
↓
|
↓
---
Ожидание
…
t
4
↓
↓
Попытка
блокировки
объекта
Р
1
отвергается
из
-
за
блокировки
,
наложенной
транзакцией
A
t
5
Ожидание
…
↓
Ожидание
…
Ожидание
…
↓
Ожидание
…
Как
видно
,
ситуация
тупика
может
возникать
при
наличии
не
менее
двух
транзакций
,
каждая
из
которых
выполняет
не
менее
двух
операций
.
На
самом
деле
в
тупике
может
участвовать
и
большее
число
транзакций
,
ожидающих
друг
друга
.
Так
как
нормального
выхода
их
тупиковой
ситуации
с
помощью
механизма
блокировок
нет
,
то
такую
ситуацию
необходимо
распознавать
и
устранять
.
Методом
разрешения
тупиковой
ситуации
является
откат
одной
из
транзакций
,
выбираемой
в
качестве
транзакции
-
жертвы
,
так
чтобы
другие
транзакции
продолжили
свою
работу
.
После
разрешения
тупика
,
транзакцию
,
выбранную
в
качестве
жертвы
необходимо
повторить
заново
.
Можно
представить
два
принципиальных
подхода
к
обнаружению
тупиковой
ситуации
и
выбору
транзакции
-
жертвы
.
1.
СУБД
не
следит
за
возникновением
тупиков
.
Транзакции
сами
принимают
решения
,
быть
ли
им
жертвой
.
2.
За
возникновением
тупиковой
ситуации
следит
сама
СУБД
,
она
же
принимает
решение
,
какой
транзакцией
пожертвовать
.
Первый
подход
характерен
для
так
называемых
персональных
СУБД
(Clipper, FoxPro
и
т
.
п
.).
Этот
метод
является
более
простым
и
не
требует
дополнительных
ресурсов
системы
.
Для
транзакций
задается
время
ожидания
(
или
число
попыток
),
в
течение
которого
транзакция
пытается
установить