Ограничение оператора SELECT в SQL Server 2005 - PullRequest
2 голосов
/ 24 марта 2009

У меня есть ситуация, когда перед выполнением конкретной задачи я должен проверить, установлен ли конкретный флаг в БД, и если он не установлен, то выполняется остальная часть обработки и устанавливается тот же флаг. Теперь, в случае одновременного доступа от 2 разных транзакций, если первая транзакция проверяет флаг и не установлена, он продолжается дальше. В то же время я хочу ограничить 2-ю транзакцию проверкой флага, т. Е. Хочу запретить этой транзакции выполнять запрос SELECT, и он может выполнить то же самое, когда 1-я транзакция завершит свою обработку и установит флаг.

Я хотел реализовать это на уровне БД с помощью блокировок / подсказок. Но никакие подсказки не ограничивают запросы SELECT, и я не могу перейти на ограничения уровня изоляции.

Ответы [ 4 ]

2 голосов
/ 24 марта 2009

Вы можете создать Application Lock для защиты вашего флага, поэтому вторая транзакция не выполнит SELECT или не получит доступ к флагу, если не сможет получить Application Lock

1 голос
/ 24 марта 2009

Я считаю, что SQL Server 2005 делает это изначально, не допуская грязного чтения. То есть, насколько я понимаю, до тех пор, пока обновление / вставка происходит до того, как второй пользователь попытается сделать выбор, чтобы проверить флаг, БД будет ожидать подтверждения обновления / вставки перед обработкой выбора.

Вот несколько распространенных блокировок , которые также могут вам помочь, если вы хотите больше детализации.

edit: XLOCK также может помочь. Также может помочь обертывание SQL в транзакции.

0 голосов
/ 24 марта 2009

Вам просто нужно просто запустить транзакцию в вашем SP / коде, а затем обновить флаг. Это заблокирует любого другого пользователя от чтения (если они не читают незафиксированное).

Если они читают незафиксированные, установите эксклюзивную блокировку для вашей транзакции обновления.

0 голосов
/ 24 марта 2009

Вы можете попробовать хранимую процедуру, которая выполняет обе задачи, или в качестве точки входа для двух разных хранимых процедур, которые выполняют разные задачи (что-то вроде прокси).

Хранимые процедуры являются мониторами в SQL Server, так же как и артефакты для управления параллелизмом (что вы хотите сделать).

...