Требуется транзакция с оптимистичным параллелизмом?

Читая этот вопрос, можно найти несколько упоминаний о том, что оптимистичный параллелизм обходится дороже во время разрешения из-за прерывания транзакций:

Оптимистическая и пессимистическая блокировка

Если вы выполняете один оператор обновления, обычно вы должны создать предложение where, чтобы гарантировать, что обновление не будет выполнено в случае конфликта. Т.е. вы должны включить исходное состояние строки в предложение where. Если кто-то другой редактировал строку и возникает конфликт, оператор обновления просто обновит нулевые записи из-за предложения where. Вам не нужно прерывать транзакцию, поскольку ваше обновление не внесло никаких изменений. Вы просто проверяете количество строк, измененных запросом (обычно это единица или ноль), и, если он изменил ноль, вы предоставляете пользователю решение о разрешении.

Если у вас нет нескольких операций, которые должны быть атомарными вместе с обновлением, я бы не подумал, что вам понадобится транзакция для одного обновления с предложением where для поддержки оптимистичного параллелизма. . Но, возможно, есть нюанс, который мне не хватает.

Вам нужна транзакция для одного оператора обновления с правильным выбором предложения where на основе исходного состояния строки (для оптимистичного параллелизма)?


sql-server optimistic-concurrency
person AaronLS    schedule 21.08.2015    source источник

Ответы (1)


arrow_upward
2
arrow_downward

В общем, вам никогда не понадобится транзакция для какого-либо одного оператора DML (Insert, Update, Delete). Каждый отдельный оператор DML является атомарным. То есть в целом он успешен или терпит неудачу. Транзакция позволяет вам сгруппировать несколько запросов DML в одну атомарную единицу работы (чтобы они выполнялись или не выполнялись как группа).

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

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

Большинство современных веб-приложений имеют следующий порядок действий:

  1. Получить данные из базы данных и отобразить их
  2. Позвольте пользователю делать свое дело.
  3. Обновите базу данных

Шаг 2 займет намного больше времени, чем два других. И модель параллелизма не помогает с этим потоком, потому что вы не можете открыть транзакцию на шаге 1 и закрыть ее на шаге 3. Итак, как вы убедитесь, что обновленные данные - это те же данные, которые были отображены. Хотя правильно сформированное обновление может предотвратить обновление, это только часть проблемы, потому что вы также должны сообщить пользователю, что его обновление не удалось.

Параметры параллелизма действительно помогают только при обработке на шаге 3. Если этот процесс выглядит так:

  1. Прочитать данные из базы данных
  2. проверьте, изменились ли данные
  3. Если он не изменился, обновите его.
  4. Сохраняем изменения в базе

Пессимистичный параллелизм гарантирует, что данные не будут изменены между шагом 1 и шагом 4; оптимистичный параллелизм ничего не гарантирует.

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

person Jeff Siver    schedule 21.08.2015
comment
Я немного педантичен, но думаю, что оптимистичный параллелизм не гарантирует, что что-то будет немного сильным. Это гарантирует, что если между шагами №1 и №4 было одновременное редактирование другим пользователем, оно будет обнаружено. Пессимистично: гарантирует, что не произойдет никакого другого промежуточного редактирования, Оптимистично: гарантирует, что промежуточные правки обнаружены, а вторичные изменения не пройдут (требуя явного разрешения) . Спасибо, что подтвердили мое понимание роли транзакции. - person AaronLS; 22.08.2015
comment
Вы правы, это было немного сильнее, чем я рассчитывал. Просто, по моему опыту, модель параллелизма играет меньшую роль в управлении обновлениями, чем мы обычно ожидаем. Кроме того, хорошее определение пессимистичного и оптимистичного в комментарии. - person Jeff Siver; 22.08.2015