Форумчане, добрый день!

Попался такой вопрос на собеседовании, приведу оригинал вопроса:

Two users are connected to a database and are about to update the some row of employee table. Before any updates occur, employee user1 salary is 10 000.
The first user begins a new transaction and then updates the salary of employee user1? giving ger a raise by issuing the following SQL statement:

UPDATE emp SET salary=salary*2 WHERE name='user1'

The second user then begins a new transaction and also updates the some employee using the following SQL statement:

UPDATE emp SET salary=salary*3 WHERE name='user1'

The first user then issues a COMMIT statement. The second user then issues a COMMIT statement.

Based on the scanario above, what is the final value of user1's salary.

Варианты ответа:
10 000, 20 000, 40 000, 50 000, 60 000

Я ответил 60 000, но я не смог объяснить внятно почему, т.к. не уверен. Какой правильный ответ и почему?

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

В SQL Server уровень изоляции по умолчанию READ COMMITTED. Значит будет ответ 60 000, верно ведь?

Видишь ли... SQL-серверов в природе как собак нерезаных, даже если считать только те, где есть транзакции... ты готов прозакладывать голову, что у ВСЕХ по дефолту именно Read Committed? Но даже если так, какая используется при этом технология - версионка или блокирование?

Насколько я помню SERIALIZABLE, вторая транзакцыя в правильном случае просто вывалится с ошыбкой. Там могут быть какие-то хаки, связанные с тем, что вторая транзакцыя не совсем началась, если в ней действительно не было никаких действий до момент UPDATE, тогда ещё можэт повиснуть. А так -- какой жэ он serializable, если в начале прочитал 10000, а потом при update ему надо прочитать 20000? Это READ COMMITED тогда, дажэ не REPEATABLE READ.

А вот википедия говорит, что такой случай называется `потерянное обновление`. От потерянного обновления защищаются все уровни изолированности, так что в любом случае - будет 20к или 30к, но не 60. 

Тест предполагал "развернутый" ответ или это просто опросник с фиксированным набором ответов?

P.S.
Ответа 30к нету? Тогда остается 20к.

Это сообщение отредактировал(а) ksnk - 15.10.2015, 11:35

При lost update в БД сохраняется значение, записанное сессией, которая последней сделала коммит. А это сессия второго юзера - т.е. без транзакций получим 30, но никак не 20.
Поскольку от такой хни транзакция гарантированно защитит - при read uncommitted выполнение второго апдейта будет заблочено до коммита в первом сеансе, затем он наконец запустится и выполнит обновление записанного первой транзакцией значения - в итоге получим 60, и опять-таки никак не 20.
20 мы получим лишь в случае, если транзакция второго юзера получит отказ (ошибка блокировки там...).

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

Ессессна. Кому нужен космонавт, который втыкает в форум? Знаешь, почём трафик на МКС? Это ж Роскосмос на одном интернете разорится.

Проверил на 2008 R2 результат 60000

Что, при любых комбинациях настроек транзакций каждого клиента, в т.ч. и различающихся?

Под дефаултными.
Под первым запустил



Под вторым


Под первым закоммитил и потом под вторым.
Кстати если первым сделать не коммит а роллбэк то результат будет 30000

Добавлено через 13 минут и 17 секунд
Вот кстати подробный разбор задачки:
http://www.besttechtools.com/articles/arti...vels-by-example

Это сообщение отредактировал(а) Garmahis - 23.10.2015, 14:00

Здесь выполняются две операции. Операция чтения и операция записи.
Уровни изоляции влияют на стратегию блокирования при чтении, не при записи. 
При записи стратегия одна - эксклюзивный лок на строку/блок и баста. Иного не придумано. Ну, если поддерживается транзакционность, конечно. Соответственно уровень изоляции по записи всегда один. 
При чтении же, даже на самом низком уровне изоляции (грязные четния), у нас вторая сессия выполняет апдейт после того, как апдейт выполнила первая сессия. Получается при грязных чтениях будет считано  salary=20000. При read comited на строку/блок/предикат накладывается шаред лок, соответственно, будет ожидаться завершение транзакции первой сессии(т.к. она захватила эксклюзив) и будет считано salary=20000. Уровни визоляции выше read commited накладывают более строгие блокировки, соответственно при любом уровне изоляции должен быть в результате 60000

Намного бы интереснее вопрос был бы, если бы первая сессия откатилась )

Тогда можно было бы подумать, что при грязных чтениях второй сессии получится 60000, а при read comited 30000. Однако смущает, что update требует эксклюзивного лока по любому, и при грязных чтениях в том числе. И если лочить до того, как читать, то грязные чтения перестанут быть грязными и дадут результат 30000. 

Еще интереснее было бы поведение при откате первой сессии, если бы у нас в where кляузе второго запроса стоял предикат where salary = 20000. Т.к. отбор требует чтения до апдейта, я полагаю при гразных чтениях второй сессии мы могли бы получить пародоксальный результат 30000. Т.к. при отборе мы отобрали бы грязную строку, а при апдейте, ее бы перечитали бы начисто. При read commited результат был бы несоменно 10000 - второй апдейт не отработал бы.

Можете кто-нибудь попробовать на платформе, разрешающей грязные чтения (у меня только оракл, там грязных чтений нет в принципе) и рассказать о результате? Ибо я очень не уверен в достоверности своих рассуждений.

Добавлено @ 11:08

нет, там разбор другого, там как работает селект, а тут как работает update

Это сообщение отредактировал(а) Zloxa - 29.12.2015, 11:58