Транзакции. Параллельное исполнение. Блокировки — различия между версиями
Nauru (обсуждение | вклад) (Новая страница: «==3 проблемы == * Проблема потерянного обновления. right * Проблема зависимости от н...») |
м (rollbackEdits.php mass rollback) |
||
(не показано 7 промежуточных версий 3 участников) | |||
Строка 1: | Строка 1: | ||
==3 проблемы == | ==3 проблемы == | ||
* Проблема потерянного обновления. | * Проблема потерянного обновления. | ||
− | [[Файл:2.jpg | + | |
+ | [[Файл:2.jpg]] | ||
* Проблема зависимости от незафиксированных результатов. | * Проблема зависимости от незафиксированных результатов. | ||
− | [[Файл:3.jpg | + | |
+ | [[Файл:3.jpg]] | ||
* Проблема анализа несовместимости. | * Проблема анализа несовместимости. | ||
+ | |||
+ | [[Файл:4.jpg]] | ||
+ | |||
+ | Транзакция А подсчитывает остатки на счетах, а | ||
+ | транзакция В переводит сумму 10 со счета 3 на счет 1. Очевидно, что результат, вырабо- | ||
+ | танный транзакцией А, — 110, является неправильным; если бы в ходе своего дальней- | ||
+ | шего выполнения транзакция А снова записала этот результат в базу данных, то фактически | ||
+ | оставила бы базу данных в противоречивом состоянии 1 . По сути, транзакция А обнару- | ||
+ | жила несовместимое состояние базы данных и поэтому выполнила анализ несовмести- | ||
+ | мости. Обратите внимание на различие между этим примером и предыдущим: в данном | ||
+ | случае не возникает проблема зависимости транзакции А от незафиксированного изме- | ||
+ | нения, поскольку в зафиксировала все свои обновления еще до того, как А прочитала | ||
+ | значение АСС 3. | ||
+ | |||
+ | ==Принцип работы блокировки == | ||
+ | 1. Прежде всего, предположим, что в системе поддерживаются блокировки двух типов: исключительные блокировки (блокировки X — exclusive) и разделяемые блокировки (блокировки S — shared), которые определены. X и S иногда именуются, соответственно, блокировками записи и блокировками чтения | ||
+ | |||
+ | 2 Если транзакция А владеет исключительной блокировкой (X), то запрос от некоторой другой транзакции в на получение блокировки кортежа t любого типа не | ||
+ | может быть немедленно удовлетворен. | ||
+ | |||
+ | 3. Если транзакция А владеет разделяемой блокировкой (S) кортежа t, то выполняются | ||
+ | следующие условия: | ||
+ | |||
+ | * запрос некоторой другой транзакции на получение блокировки X кортежа t | ||
+ | не может быть немедленно удовлетворен; | ||
+ | |||
+ | * запрос некоторой другой транзакции на получение блокировки S кортежа t | ||
+ | может и должен быть немедленно удовлетворен | ||
+ | (это означает, что с этого времени транзакция также будет владеть | ||
+ | блокировкой S кортежа). | ||
+ | |||
+ | ==Протокол блокировки== | ||
+ | 1. Транзакция, в которой требуется выполнить выборку кортежа, должна вначале приобрести блокировку S на этот кортеж. | ||
+ | |||
+ | 2. Транзакция, в которой требуется выполнить обновление кортежа, должна вначале приобрести X блокировку на этот кортеж. В ином случае, если она уже владеет блокировкой S на этом кортеже, как происходит в ситуации, когда выполняется последовательность операций выборки и обновления (RETRIEVE и UPDATE), то эта транзакция должна повысить уровень блокировки S до уровня X. | ||
+ | |||
+ | 3. Если запрос на блокировку от транзакции в не может быть немедленно удовлетворен из-за того, что он конфликтует с блокировкой, которой уже владеет транзакция А, то в переходит в состояние ожидания. Транзакция в ожидает до тех пор, пока не появится возможность удовлетворить ее запрос на блокировку, а это может произойти не раньше, чем транзакция А освободит блокировку. |
Текущая версия на 19:34, 4 сентября 2022
3 проблемы
- Проблема потерянного обновления.
- Проблема зависимости от незафиксированных результатов.
- Проблема анализа несовместимости.
Транзакция А подсчитывает остатки на счетах, а транзакция В переводит сумму 10 со счета 3 на счет 1. Очевидно, что результат, вырабо- танный транзакцией А, — 110, является неправильным; если бы в ходе своего дальней- шего выполнения транзакция А снова записала этот результат в базу данных, то фактически оставила бы базу данных в противоречивом состоянии 1 . По сути, транзакция А обнару- жила несовместимое состояние базы данных и поэтому выполнила анализ несовмести- мости. Обратите внимание на различие между этим примером и предыдущим: в данном случае не возникает проблема зависимости транзакции А от незафиксированного изме- нения, поскольку в зафиксировала все свои обновления еще до того, как А прочитала значение АСС 3.
Принцип работы блокировки
1. Прежде всего, предположим, что в системе поддерживаются блокировки двух типов: исключительные блокировки (блокировки X — exclusive) и разделяемые блокировки (блокировки S — shared), которые определены. X и S иногда именуются, соответственно, блокировками записи и блокировками чтения
2 Если транзакция А владеет исключительной блокировкой (X), то запрос от некоторой другой транзакции в на получение блокировки кортежа t любого типа не может быть немедленно удовлетворен.
3. Если транзакция А владеет разделяемой блокировкой (S) кортежа t, то выполняются следующие условия:
* запрос некоторой другой транзакции на получение блокировки X кортежа t не может быть немедленно удовлетворен;
* запрос некоторой другой транзакции на получение блокировки S кортежа t может и должен быть немедленно удовлетворен (это означает, что с этого времени транзакция также будет владеть блокировкой S кортежа).
Протокол блокировки
1. Транзакция, в которой требуется выполнить выборку кортежа, должна вначале приобрести блокировку S на этот кортеж.
2. Транзакция, в которой требуется выполнить обновление кортежа, должна вначале приобрести X блокировку на этот кортеж. В ином случае, если она уже владеет блокировкой S на этом кортеже, как происходит в ситуации, когда выполняется последовательность операций выборки и обновления (RETRIEVE и UPDATE), то эта транзакция должна повысить уровень блокировки S до уровня X.
3. Если запрос на блокировку от транзакции в не может быть немедленно удовлетворен из-за того, что он конфликтует с блокировкой, которой уже владеет транзакция А, то в переходит в состояние ожидания. Транзакция в ожидает до тех пор, пока не появится возможность удовлетворить ее запрос на блокировку, а это может произойти не раньше, чем транзакция А освободит блокировку.