Стратегии параллелизма

В любых многопользовательских приложениях, включая Web-приложения, существует потенциальная возможность того, что два и более пользователя будут выполнять перекрывающиеся запросы и обновления. Это может привести к потенциально запутанной ситуации, в которой два пользователя, каждый из которых обладает текущим состоянием строки, попытаются одновременно выполнить различающиеся обновления. Обновление первого пользователя всегда будет успешным. Успех или неудача второго обновления определяется применяемой стратегией параллелизма.

Существует несколько распространенных подходов к управлению параллелизмом. Наиболее важно понять, что вы определяете эту стратегию способом написания команд UPDATE (в частности, способом формирования конструкции WHERE). Вот наиболее типичные примеры:

• Обновление "последний выигрывает". Это наименее ограничивающая форма управления параллелизмом, в которой обновление всегда подтверждается (если только исходная строка не была удалена). Всякий раз, когда фиксируется обновление, применяются все значения полей. Обновление "последний выигрывает" имеет смысл, если коллизии данных относительно редки. Например, вы можете успешно использовать этот подход, если только одно лицо ответственно за обновление данной группы записей. Обычно такая стратегия реализуется написанием конструкции WHERE, идентифицирующим обновляемую строку на основе поля первичного ключа. Метод UpdateEmployee() в предыдущем примере использует именно такой подход.
  
  UPDATE Employees SET ... WHERE EmployeeID=@ID
• Обновление при полном соответствии. Чтобы реализовать эту стратегию, вы добавляете конструкцию WHERE, которая пытается сравнить текущие значения всех полей в операторе UPDATE. Таким образом, даже если единственное поле было модифицировано в параллельном сеансе, запись не будет соответствовать старому состоянию, а потому обновление не удастся. Например, если два пользователя пытаются модифицировать разные части одной и той же записи, то запрос обновления от второго пользователя будет отклонен, даже если он не приводит к конфликту. Другая, более существенная проблема стратегии полного соответствия состоит в том, что она порождает громоздкие, неэффективные операторы SQL. Вы можете реализовать ее более эффективно с помощью временных меток (см. следующий абзац).
  
  UPDATE Employees SET ...
  WHERE EmployeeID=@ID AND FirstName=@FirstName
  AND LastName=@LastName ...
• Обновление на базе временных меток. Большинство систем баз данных поддерживают столбцы временных меток, которые источник данных обновляет автоматически при каждом обновления записи. Нет необходимости модифицировать их вручную. Однако вы можете проверять их изменение, и таким образом определять, что другой пользователь недавно применил свое обновление. Если вы напишете оператор UPDATE с конструкцией WHERE, которая включает первичный ключ и текущую временную метку, то вы гарантировано обновите запись только в том случае, если она не была модифицирована — как и в случае обновления при полном соответствии.
  
  UPDATE Employees SET ...
  WHERE EmployeeID=@ID
  AND TimeStamp=@TimeStamp

 

предыдущая    следующая страница   оглавление

346