WikiDer > Блокировка записи
эта статья нужны дополнительные цитаты для проверка. (Декабрь 2009 г.) (Узнайте, как и когда удалить этот шаблон сообщения) |
Блокировка записи это метод предотвращения одновременного доступа к данным в база данных, чтобы предотвратить противоречивые результаты.
Классический пример демонстрируют два банка клерки, пытающиеся обновить то же самое банковский счет для двух разных транзакций. Клерки 1 и 2 получают (т. Е. Копируют) учетную запись запись. Клерк 1 применяет и сохраняет транзакцию. Клерк 2 применяет другую транзакцию к своей сохраненной копии и сохраняет результат на основе исходной записи и его изменений, перезаписывая транзакцию, введенную служащим 1. Запись больше не отражает первую транзакцию, как если бы она никогда не имела места.
Простой способ предотвратить это - заблокировать файл всякий раз, когда запись изменяется каким-либо пользователем, так что ни один другой пользователь не может сохранять данные. Это предотвращает неправильную перезапись записей, но позволяет обрабатывать только одну запись за раз, блокируя других пользователей, которым необходимо редактировать записи одновременно.
Чтобы разрешить нескольким пользователям редактировать таблицу базы данных одновременно, а также предотвратить несоответствия, возникающие из-за неограниченного доступа, одна запись может быть заблокирован при получении для редактирования или обновления. Любой, кто пытается получить ту же запись для редактирования, лишается доступа на запись из-за блокировки (хотя, в зависимости от реализации, они могут просматривать запись, не редактируя ее). После сохранения записи или отмены редактирования блокировка снимается. Записи никогда не могут быть сохранены, чтобы перезаписать другие изменения, сохраняя целостность данных.
В теории управления базами данных блокировка используется для реализации изоляция среди нескольких пользователей базы данных. Это «я» в аббревиатуре КИСЛОТА.
Подробное и авторитетное описание блокировки было написано Джим Грей.[1]
Детализация блокировок
Если банковские служащие (как показано на рисунке выше) обслуживают двух клиентов, но их счета хранятся в одной бухгалтерской книге, то вся бухгалтерская книга или одна или несколько таблицы базы данных, необходимо сделать доступными для редактирования клеркам, чтобы каждый мог выполнить транзакцию по одному (блокировка файлов). Хотя этот метод безопасен, он может вызвать ненужное ожидание.
Если клерки могут удалить одну страницу из бухгалтерской книги, содержащую учетную запись текущего клиента (плюс несколько других учетных записей), то можно будет обслуживать несколько клиентов. одновременнопри условии, что учетная запись каждого клиента находится на другой странице, чем другие. Если у двух клиентов есть учетные записи на одной странице, то одновременно может обслуживаться только один. Это аналогично блокировка уровня страницы в базе данных.
Более высокая степень детализация достигается, если клерк может вести каждый отдельный счет. Это позволит обслуживать любого клиента, не дожидаясь, пока другой клиент получит доступ к другой учетной записи. Это аналогично блокировка уровня записи и обычно является наивысшей степенью детализации блокировки в системе управления базами данных.
В SQL В базе данных запись обычно называется «строкой».
Введение детальных (подмножественных) блокировок создает возможность для ситуации, называемой тупик. Тупик возможен, когда инкрементная блокировка (блокировка одного объекта, затем блокировка одного или нескольких дополнительных объектов). Например, если два клиента банка попросят двух клерков получить информацию об их счетах, чтобы они могли перевести деньги на другие счета, эти два счета будут по существу заблокированы. Затем, если клиенты сообщали своим клеркам, что деньги должны быть переведены на счета друг друга, клерки будут искать другие счета, но обнаруживают, что они «используются», и ждут их возврата. По незнанию, два клерка ждут друг друга, и ни один из них не может завершить свою транзакцию, пока другой не сдастся и не вернет счет. Чтобы избежать таких проблем, используются различные методы.
Использование замков
Между объектами, запрашивающими записи, необходимо управлять блокировками записей, чтобы ни один объект не получил слишком много услуг через последовательные гранты, и никакая другая сущность не заблокирована. Сущности, запрашивающие блокировку, могут быть как отдельными приложениями (программами), так и целым процессором.
Приложение или система должны быть спроектированы таким образом, чтобы любая блокировка удерживалась в течение как можно более короткого времени. Чтение данных без средств редактирования не требует блокировки, и чтение заблокированных записей обычно допустимо.
Могут быть запрошены два основных типа замков:
Эксклюзивные замки
Эксклюзивные блокировки, как следует из названия, удерживаются исключительно одним объектом, обычно с целью записи в запись. Если схема блокировки была представлена списком, список владельцев будет содержать только одну запись. Поскольку этот тип блокировки эффективно блокирует любой другой объект, для обработки которого требуется блокировка, необходимо соблюдать осторожность, чтобы:
- обеспечить удержание замка в кратчайшие сроки;
- не удерживать блокировку между вызовами системы или функций, если объект больше не работает на процессоре - это может привести к тупиковой ситуации;
- убедитесь, что при неожиданном выходе из объекта по какой-либо причине блокировка снимается.
Те, кто не владеет замком (a.k.a. официанты) может храниться в списке, который обслуживается циклически, или в ФИФО очередь. Это гарантирует, что любой возможный официант получит равные шансы получить блокировку и не будет заблокирован. Чтобы еще больше ускорить процесс, если объект перешел в спящий режим в ожидании блокировки, производительность улучшается, если объект уведомляется о предоставлении разрешения, вместо того, чтобы обнаруживать его при пробуждении по некоторому типу системного тайм-аута.
Общие блокировки отличаются от эксклюзивных блокировок тем, что список владельцев может содержать несколько записей. Совместные блокировки позволяют всем держателям читать содержимое записи, зная, что запись не может быть изменена до тех пор, пока блокировка не будет снята всеми держателями. Исключительные блокировки не могут быть получены, если запись уже заблокирована (монопольно или совместно) другим объектом.
Если запросы блокировки для одного и того же объекта помещены в очередь, то после предоставления разделяемой блокировки также могут быть предоставлены любые поставленные в очередь разделяемые блокировки. Если исключительная блокировка находится следующей в очереди, она должна дождаться снятия всех общих блокировок. Как и в случае с монопольными блокировками, эти разделяемые блокировки должны удерживаться как можно меньше времени.
Смотрите также
использованная литература
- ^ Грей, Джим и Рейтер, Андреас (1993), Распределенная обработка транзакций: концепции и методы, Морган Кауфманн, стр.375–437, ISBN 1-55860-190-2