Условие гонки между select и update

Question

Мне нужно обновить строку в базе данных Oracle таким образом, чтобы я не заслонял изменения от другого клиента в своем веб-приложении.

В моей нынешней системе я выполнить следующие действия:

SELECT * FROM table WHERE id=:ID AND lastmodified=:LASTMOD 

, если строка еще существует с тем же дату последнего изменения, когда мы начинали, мы знаем, что никто не изменил его, чтобы мы могли обновить с помощью последнего изменения.

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

Конечным результатом является то, что я сжимаю изменения другого пользователя, и нет предупреждения о его возникновении.

Я думал об использовании SELECT FROM UPDATE, но, видимо, это bad idea (особенно для веб-приложений), статья рекомендует перечитывать (это то, что я делаю выше), но я все же думаю, что я подвергаюсь риску состояние гонки.

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

Answer 1

Я предполагаю, что ваш оператор UPDATE проверяет значение lastmodified, которое вы читаете в своем заявлении SELECT, как предполагает предложение.

lastmodified Если это DATE, то есть потенциал состояние гонки, если есть несколько обновлений в той же строке в ту же секунду поскольку DATE только имеет зернистость ко второму. Если lastmodified является TIMESTAMP, с другой стороны, окно, в котором может происходить условие гонки, гораздо более ограничено, так как TIMESTAMP будет иметь от 3 до 9 цифр точности второй секунды (3 на большинстве машин Windows, 6 на большинстве Unix машины). Маловероятно, но не исключено, что у вас будет два обновления за одну и ту же миллисекунду или даже одну и ту же микросекунду. Но это не непогрешимо.

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

Answer 2

один подход можно принять, что, когда пользователь обновляет таблицу, они добавляют

AND lastmodified = :LASTMOD 

в пункте заявления обновления WHERE, где :LASTMOD это значение, возвращенное пользователем изначальном выберите. Если обновление затронуло теперь строки (SQL%ROWCOUNT=0), то вы знаете, что второй пользователь обновил эту строку, поскольку первый пользователь изначально запускал свой выбор.

Answer 3

Я не уверен в внутреннем решении SQL, но предполагаю, что вы используете некоторый язык сценариев (php? Perl?) Для работы с веб-приложением/бэкэндом, поэтому вы можете просто использовать их для использования файла блокировки или семафора/мьютекса для блокировки записи и ожидания (если заблокирован) или просто попросите пользователя подождать минуту и ​​повторите попытку.

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

Answer 4

Другим вариантом является включение ROWDEPENDENCIES на стол (что требует восстановления таблицы!) И использование псевдокоманды ORA_ROWSCN. Отслеживание SCN на уровне строки и блочного уровня составляет 6 байт в строке; однако это меньше, чем столбец DATE или TIMESTAMP и не требует создания дополнительных объектов - например, последовательности или триггера, чтобы убедиться, что эта последовательность заполнена.

Для получения дополнительной информации см. Вопрос Актома Тома Ките here.