none
Что такое Concurrency Violation и как работать с этим в ADO.NET RRS feed

  • Общие обсуждения

  • Когда несколько пользователей пытаются одновременно изменить данные, необходима установка элементов управления для предотвращения взаимного неблагоприятного влияния изменений, внесенных одновременно разными пользователями. Система управления действиями в таких случаях называется управлением параллелизмом.

    Существует три распространенных способа для управления одновременным доступом в базе данных:

          1) Пессимистическая блокировка: строка недоступна пользователям с момента извлечения записи до момента ее обновления в базе данных.

          2) Оптимистическая блокировка: строка недоступна другим пользователям только во время текущего обновления данных. Обновление проверяет строку в базе данных и определяет наличие изменений. Попытка обновления уже измененной записи вызывает нарушение одновременного доступа.

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

    Пессимистическая блокировка обычно используется по двум причинам. Первая заключается в том, что в некоторых случаях имеет место высокая состязательность за доступ к некоторым записям. Издержки блокировки данных меньше издержек отката изменений при возникновении конфликтов одновременного доступа.

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

    При оптимистической блокировке данные блокируются только на время обращения к базе данных. Блокировки препятствуют попыткам других пользователей обновить записи одновременно. Данные всегда доступны, за исключением времени, в течение которого происходит обновление. Дополнительные сведения см. в разделе Оптимистичный параллелизм (ADO.NET) (http://msdn.microsoft.com/ru-ru/library/aa0416cz%28v=VS.90%29.aspx ).

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

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

          Пользователь А извлекает запись из базы данных.

          Пользователь B извлекает ту же запись из базы данных, изменяет ее и записывает обновленную запись в базу данных.

          Пользователь A изменяет "старую" запись и записывает ее в базу данных.

    В вышеприведенном сценарии изменения, сделанные пользователем B, не видны пользователю A. Если такая ситуация является приемлемой, подход "последний побеждает" можно использовать для управления одновременным доступом.

    (более подробно смотрите в разделе http://msdn.microsoft.com/ru-ru/library/cs6hb8k4%28v=VS.90%29.aspx )

    3 ноября 2010 г. 12:16