19. Управление параллельной обработкой данных. Блокировки.

При одновременной работе с базой данных нескольких клиентских приложений необходимо предотвращать непредусмотренное влияние действий одного пользователя на действия другого. При этом требования, накладываемые различными пользователями, различны. Например, можно потребовать, чтобы пользовательское приложение получило такие же результаты, как и в случае монопольной работы с базой данных. В других случаях подразумевается, что действия одних пользователей могут влиять на действия других, но ожидаемым образом.

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

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

Иными словами, в начале транзакции выполняется оператор SELECT, а в конце – оператор UPDATE. Доступ к промежуточным данным. Предположим, что один из пользователей имеет доступ к промежуточным данным, внесенным в базу данных в процессе выполнения какой-то другой транзакции. Тогда при откате этой транзакции результаты вычислений будут ошибочными. Строки – фантомы. Если одна из транзакций несколько раз выполняет один и тот же запрос, может получиться, что результаты выполнения этого запроса будут различными. Так, может произойти ситуация, когда перед выпиской билета кассир запрашивает количество мест каждого вида (нижних, верхних, боковых и т.д.), а потом спрашивает у покупателя, какое место тот желает. При повторном запросе желаемого места его может и не оказаться!

Блокировка – это механизм, предназначенный для предотвращения некорректного изменения данных при параллельной и асинхронной работе пользователей распределенной системы. Блокировка используется: для обеспечения гарантированной неизменности данных другими пользователями в рамках транзакции; для обеспечения естественного временного порядка изменений, проводимых в базе данных.

Можно заблокировать всю базу данных, отдельную таблицу, строку или набор строк, а также отдельные столбцы таблицы. Размер блокируемого ресурса иногда называют глубиной детализации блокировки. Очевидно, при большей глубине детализации администрирование базы данных выполняется достаточно легко, но в этом случае конфликты из-за блокировки могут наступить гораздо чаще, чем при блокировании, например, отдельных строк. Можно также выполнить монопольную или коллективную блокировку. При монопольной блокировке никакая другая транзакция не может даже прочитать заблокированные данные. При коллективной блокировке данные остаются доступными для чтения, но не для изменения. Различают оптимистические и пессимистические стратегии блокировки. При оптимистической блокировке делается предположение, что конфликта не произойдет. Данные считываются, обрабатываются, обновления заносятся в базу данных. И лишь после этого производится проверка того, не возник ли конфликт. Если конфликта нет, то транзакция завершается. В противном случае транзакция повторяется до тех пор, пока она не сможет успешно завершиться. Пессимистическая блокировка предполагает, что конфликт обязательно произойдет, и нам обязательно надо заблокировать изменяемые записи до начала вычислений. При этом, конечно же, проверка правильности транзакции не нужна.

Одним из неприятных побочных эффектов блокировки является возникновение тупиковых ситуаций. Есть два наиболее распространенных способа решения этой проблемы: не допускать тупиковых ситуаций либо ничего не делать для их предотвращения, но в случае наступления тупиковой ситуации снимать одну из транзакций.

Для блокировки всей таблицы используется оператор LOCK TABLE, а для отдельных строк таблицы – фраза FOR UPDATE в операторе SELECT. Различают следующие типы блокировки:

В режиме SHARE разрешаются запросы, но запрещаются изменения в таблице. Режим EXCLUSIVE разрешает запросы к таблице, но запрещает любые другие действия. ROW SHARE разрешает одновременный доступ к таблице нескольким процессам, но запрещает в дальнейшем одному из них захватить таблицу монопольно. ROW EXCLUSIVE выполняет те же функции, что и ROW SHARE, но запрещает дальнейший захват в режиме SHARE. Этот режим блокировки автоматически устанавливается в операторах модификации данных. SHARE ROW EXCLUSIVE используется для просмотра всей таблицы и разрешает другим пользователям просмотр строк таблицы, но запрещает им блокировать таблицу в режиме SHARE или изменять строки.