Добрый день.

Есть WEB сервер, модуль которого подключается к базе и вносит изменения в таблицу-счётчик. На сколько я понимаю в один момент времени на web сервер может придти "куча" запросов, и в один миг идут множество запросов в базу.

существует хранимая процедура, например скрипт самый простой:



К примеру [Inc_Fild] = 100, в один момент времени пришло 100 запросов на web сервер, модуль которого которого стал вызывать хранимку в ста разных потоках. Если не делать BEGIN TRANSACTION, при завершении выполнения 100 запросов [Inc_Fild] будет равен "0", или же нет? Я к чему, может ли быть ситуация когда, первый поток вызова процедуры вносит изменения в БД а второй читает как бы "грязные" данные, изменения которых ещё не произошли? Или же MSSQL не позволит этого сделать, и выполнения множества потоков встанет в очередь и будет выполнение одно за другим?

stiВсе одиночные запросы выполняются в неявной транзакции

И что это значит?

Вот про что я говорю, из статьи выше:

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

Предположим, имеются две транзакции, выполняемые одновременно:

Транзакция 1 Транзакция 2
UPDATE tbl1 SET f2=f2+20 WHERE f1=1; UPDATE tbl1 SET f2=f2+25 WHERE f1=1;
В обеих транзакциях изменяется значение поля f2, по их завершении значение поля должно быть увеличено на 45. В действительности может возникнуть следующая последовательность действий:

Обе транзакции одновременно читают текущее состояние поля. Точная физическая одновременность здесь не обязательна, достаточно, чтобы вторая по порядку операция чтения выполнилась до того, как другая транзакция запишет свой результат.
Обе транзакции вычисляют новое значение поля, прибавляя, соответственно, 20 и 25 к ранее прочитанному значению.
Транзакции пытаются записать результат вычислений обратно в поле f2. Поскольку физически одновременно две записи выполнить невозможно, в реальности одна из операций записи будет выполнена раньше, другая позже. При этом вторая операция записи перезапишет результат первой.
В результате значение поля f2 по завершении обеих транзакций может увеличиться не на 45, а на 20 или 25, то есть одна из изменяющих данные транзакций «пропадёт».




У меня вопрос, если не делать BEGIN TRANSACTION и COMMIT TRANSACTION, может случиться так, что одна транзакция может быть утеряна?

stiИгорь_UUSУ меня вопрос, если не делать BEGIN TRANSACTION и COMMIT TRANSACTION, может случиться так, что одна транзакция может быть утеряна?
Ещё раз - Все одиночные запросы выполняются в неявной транзакции. Так что абсолютно всё равно делай или не делай BEGIN TRANSACTION и COMMIT TRANSACTION.

Вроде как нет. Если делать только BEGIN TRANSACTION, то другая транзакция не может изменить данные, которые обрабатываются в первой, до момента её завершения

TaPaKИгорь_UUS,

а если сделать два BEGIN TRAN два COMMIT и один SAVE TRAN, то транзакция будет немного светиться

Вы так и не можете дать внятного ответа... то ли "да" то ли "нет".

Как должен выглядеть TSQL, чтоб гарантировать пропадания какого либо Update'та?

Гавриленко Сергей Алексеевич


Спасибо, почитал, похоже то что надо. Но в описании говориться, что необходимо обязательно открыть транзакцию т.е. где-то выше должно быть BEGIN TRANSACTION

это так? или BEGIN TRANSACTION можно и не делать?

Гавриленко Сергей АлексеевичИгорь_UUSпропущено...


Спасибо, почитал, похоже то что надо. Но в описании говориться, что необходимо обязательно открыть транзакцию т.е. где-то выше должно быть BEGIN TRANSACTION

это так? или BEGIN TRANSACTION можно и не делать?Вы ответы принципиально не читаете? Написали же все в первом же ответе: 21159923


Вы меня запутали, при чём тут не явные транзакции??? Я не использую вообще SET IMPLICIT_TRANSACTIONS ON

мне нужно обратиться к таблице, заблокировать одну запись c заданным ID, внести в неё изменения. В момент блокировки записи, все параллельные изменения не должны вноситься до её разблокировки. Или заблокировать всю таблицу (не желательно, но если другого гарантированного варианта нет, пускай будет всю)

TaPaKИгорь_UUS,

ответ вам уже дан. Если осилили прочитать про нейвные, прочитайте и про явные и неожиднный autocommit
https://technet.microsoft.com/en-us/library/ms187878(v=sql.105).aspx

всё понятно... выполнение любой операции это и есть транзакция, если нет явной происходит autocommit после каждого действия...
спасибо!

invmИгорь_UUSмне нужно обратиться к таблице, заблокировать одну запись c заданным ID, внести в неё изменения. В момент блокировки записи, все параллельные изменения не должны вноситься до её разблокировки.Ответы не читаете? Или не понимаете прочитанное?
Еще раз - конкурирующие update никогда не вызовут "потерянных изменений". Никаких дополнительных манипуляций не требуется.

Я реально запутался))) Дак надо что-то применять или нет... тут пишут то ли надо, то ли не надо

invmИгорь_UUSЯ реально запутался))) Дак надо что-то применять или нет... тут пишут то ли надо, то ли не надоДумаете я зря рекомендовал про блокировки читать. Вот прочли бы и перестали путаться.

При updat'е происходит примерно следующее - при считывании значения изменяемого столбца на строку таблицы накладывается U-блокировка (может и сразу X). И это гарантирует, что никакие конкурирующие писатели (update, delete и т.п.) не смогут прочитать значения из этой строки до снятия блокировки.
Потому что они тоже захотят наложить U и не смогут, ибо U не совместима с другой U или X.

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