Предотвращает ли «выбор для обновления» вставку других соединений при отсутствии строки
Меня интересует, будет ли запрос select for update заблокировать не -существующая строка.
Например,
Таблица FooBar с двумя столбцами, foo и bar, foo имеет уникальный индекс
- Запрос на выдачу
Панель выбора из FooBar, где foo =? для обновления - Если запрос возвращает ноль строк foo и bar, foo имеет уникальный индекс Панель выбора запроса на выдачу из FooBar, где ...
Меня интересует, будет ли запрос
select for updateзаблокировать несуществующую строку.например,
Таблица FooBar с двумя столбцами, foo и bar, foo имеет уникальный индекс
- Запрос на выдачу
Панель выбора из FooBar, где foo =? для обновления - Если запрос возвращает ноль строк foo и bar, foo имеет уникальный индекс Панель выбора запроса на выдачу из FooBar, где ...
Меня интересует, будет ли запрос
select for updateзаблокировать несуществующую строку.например,
Таблица FooBar с двумя столбцами, foo и bar, foo имеет уникальный индекс
- Запрос на выдачу
Панель выбора из FooBar, где foo =? для обновления - Если запрос возвращает ноль строк
- Запрос вставки
вставляет в значения FooBar (foo, bar) (?,?)
- Запрос вставки
Теперь возможно, что вставка вызовет нарушение индекса или выбор
для обновленияпредотвращает что?Интересует поведение на SQLServer (2005/8), Oracle и MySQL.
- Запрос на выдачу
- Запрос на выдачу
4 ответа
В Oracle оператор SELECT ... FOR UPDATE не влияет на несуществующую строку (оператор просто вызывает исключение No Data Found). Оператор INSERT предотвратит дублирование значений уникального/первичного ключа. Любые другие транзакции, пытающиеся вставить те же значения ключа, будут блокироваться до тех пор, пока первая транзакция не зафиксируется (в это время заблокированная транзакция получит ошибку дублирующего ключа) или не откатится (в это время заблокированная транзакция продолжится).
Я написал подробный анализ этой штуки на SQL Server: Разработка модификаций, способных выдержать параллелизм
В любом случае, вам нужно использовать уровень изоляции SERIALIZABLE, и вам действительно нужно стресс-тестирование .
В Oracle:
Сеанс 1
create table t (id number);
alter table t add constraint pk primary key(id);
SELECT *
FROM t
WHERE id = 1
FOR UPDATE;
-- 0 rows returned
-- this creates row level lock on table, preventing others from locking table in exclusive mode
Сеанс 2
SELECT *
FROM t
FOR UPDATE;
-- 0 rows returned
-- there are no problems with locking here
rollback; -- releases lock
INSERT INTO t
VALUES (1);
-- 1 row inserted without problems
SQL Server имеет только FOR UPDATE как часть курсора. И это применимо только к операторам UPDATE, связанным с текущей строкой в курсоре.
Итак, FOR UPDATE не имеет отношения к INSERT. Поэтому я думаю, что ваш ответ заключается в том, что это неприменимо в SQL Server.
Теперь можно смоделировать поведение FOR UPDATE с транзакциями и стратегиями блокировки. Но это может быть больше, чем то, что вы ищете.