Пример реального уровня изоляции SQL Server
Допустим, нам нужно разработать приложение для ставок, например, на eBay. Мы не хотим, чтобы ставки одного пользователя блокировали ставки другого пользователя, что приведет к медленному ответу. Кроме того, когда я делаю ставку, основанную на самой высокой цене, которую я вижу, я не хочу, чтобы приложение показывало, что извините, самая высокая цена больше не была той же самой; пока я делаю ставку, кто-то подтолкнул цену выше.
Какой уровень изоляции мы должны использовать? Я думал о Read Uncommittedдля грязного чтения и без блокировки, но не уверен.
Я хотел бы услышать больше реальных примеров / случаев использования для уровня изоляции в SQL Server (или вообще, любом другом программном обеспечении для баз данных, если между ними есть сходства в отношении уровней изоляции). Для меня это не очень эффективно, просто смотреть на определения.
Спасибо.
1 ответ
READ UNCOMMITTED звучит примерно так, в контексте сценария, который вы представляете... но этот сценарий звучит довольно плохо!
когда я делаю ставку, основываясь на самой высокой цене, которую я вижу, я не хочу, чтобы в конце приложение показывало, что извините, самая высокая цена больше не совпадает; пока я делаю ставку, кто-то подтолкнул цену выше.
Может быть, я неправильно понимаю, но вы имеете в виду, если кто-то еще предлагал цену, пока вы готовили свою ставку? Если так, как еще это должно работать? Вы выиграете, хотя ставку ниже, просто потому, что время начала ставки было раньше? Это не сработает. Это должно быть решено во время подачи вашей заявки.
На самом деле, это должно работать с READ COMMITTED, так что на ставку пользователя влияют все предыдущие - в тот момент, когда она была отправлена. Это требование разумного аукциона. Заявки должны проходить во временной последовательности, обернутой TRANSACTIONs, и всегда должны соответствовать последнему максимуму на момент начала транзакции, т. е. когда пользователь нажимает кнопку "Отправить", он должен соответствовать сумме всех ставок, поданных до их.