Здраствуйте!

Есть база на сервере, все работает так: пользователи заходят и могут прочитать, обработать и изменить определенные записи в определенной таблице базы. (SQL Server 2005). Пользователей достаточно много и очень вероятна ситуация когда два и более пользователей будут одновременно менять одну и ту же запись.
Pessimistic concurency мне не подходит, потому что нельзя блокировать полностью запись, а optimistic concurrency подходит. Не могли бы вы пояснить как лучше использовать optimistic concurrency в ASP.NET приложениях, то есть с учетом специфики веб-приложений. Привести какой нибудь кусок кода или дать ссылку на реализацию optimistic concurrency в веб-приложении ASP.NET.

Здравствуйте, stump, Вы писали:

S>Я не вижу особой специфики для реализации оптимистической блокировки. Обычно она локализуется на уровне доступа к данным и более высокие уровни приложения (бизнес-логика и UI) о ней вообще ничего не знают.
S>Существует два основных способа реализации оптимистической блокировки.
S>1. При сохранении изменений в БД используем "update" с фильтром "where" не только по первичному ключу таблицы а по всем ее полям. При этом если нужная нам запись была изменена другим пользователем наш update не обновит запись. Поэтому мы проверяем результат апдейта и если число обновленных строк равно нулю, сигналим "наверх" возбуждая исключение. Недостатоук этого способа в том что нам необходимо хранить старое значение записи. В условиях ASP.NET приложения нам наверняка придется делать это в сессии или viewstate, что не очень удобно.

S>2. В таблицу добавляется соответствующее поле для отметки версии записи. Это может быть поле типа int или datetime. Перед сохранением данных мы производим перварительное чтение по первичному ключу записи из базы (вернее одного поля версии) и сравниваем версию в записи в БД с версией своей записи. Если версии совпадают, мы увеличиваем на 1 версию своей записи и сохранияем ее. Если нет — кто то изменил нашу запись и ее нельзя сохранять. Естественно операцию предварительного чтения вернсии и сохранения записи надо проводить в SQL транзакции. Недостаток этого способа — необходимо предварительное чтение версии записи, что дополнительно нагружает БД.

Еще хочу пояснение сделать следующее, мне необходимо сделать так, чтобы абсолютно все обновления записи были произведены, то есть, если в результате апдейта выяснилось, что запись уже была обновлена, необходимо я так предполагаю заново её прочитать, снова произвести те же изменения и попытаться сохранить, если опять она была обновлена кем то, то все повторяется снова. Вот самый главный вопрос, как именно такую схему лучше реализовать в ASP.NET? Я знаю что в DataSet'ах ADO.NET реализованы механизмы позволяющие использовать оптимистическую блокировку, только вот вопрос то в том, как это делать если я использую её в веб-приложении? У меня основная цель — сильно не грузить сервер. Например вот такой алгоритм пойдет или нет? :

1) читаю запись из таблицы
2) выполняю действия по её изменению (в коде)
3) пытаюсь обновить запись в базе
4) если запись была обновлена кем то еще (экзепнш) , то возврат на пункт 1)

таким образом запись когда нибудь да обновится я думаю =), только вот вопрос в том, сильно ли это будет круто для сервера на котором лежит мое приложение?

А>Еще хочу пояснение сделать следующее, мне необходимо сделать так, чтобы абсолютно все обновления записи были произведены, то есть, если в результате апдейта выяснилось, что запись уже была обновлена, необходимо я так предполагаю заново её прочитать, снова произвести те же изменения и попытаться сохранить, если опять она была обновлена кем то, то все повторяется снова. Вот самый главный вопрос, как именно такую схему лучше реализовать в ASP.NET? Я знаю что в DataSet'ах ADO.NET реализованы механизмы позволяющие использовать оптимистическую блокировку, только вот вопрос то в том, как это делать если я использую её в веб-приложении? У меня основная цель — сильно не грузить сервер. Например вот такой алгоритм пойдет или нет? :

А>1) читаю запись из таблицы
А>2) выполняю действия по её изменению (в коде)
А>3) пытаюсь обновить запись в базе
А>4) если запись была обновлена кем то еще (экзепнш) , то возврат на пункт 1)

А>таким образом запись когда нибудь да обновится я думаю =), только вот вопрос в том, сильно ли это будет круто для сервера на котором лежит мое приложение?

Короче говоря, вообще я читал статьи и посты в форумах на тему использования оптимистических блокировок в ASP.NET, там подход такой — обновляем запись, если эксепшн, то редиректим юзера на страницу где написано, что не удалось выполнить ваш запрос потому что кто то это сделал раньше вас, попробуйте снова.
А у меня немного другая схема, моему пользователю до лампочки почему там не удалось обновить данные, это просто надо сделать и все.
То есть приложение должно пытаться и пытаться это сделать пока все таки эта запись не будет вставлена в таблицу =).

Я все таки решил использовать такой подход:

1) читаю запись из таблицы
2) выполняю действия по её изменению (в коде)
3) пытаюсь обновить запись в базе
4) если запись была обновлена кем то еще (экзепнш) , то возврат на пункт 1)

вопрос такой: как лучше в таком случае реализовать, например так:

1) открываю соединение к базе
2) читаю нужную запись SqlDataReader'ом
3) закрываю соединение
4) произвожу изменение записи в своем коде
5) снова открываю соединение к базе
6) делаю апдейт с помощью rowsupdated = SqlCommand.ExecuteNonQuery(); запрос при этом типа такого

UPDATE Table1 Set Col1 = @NewCol1Value,
Set Col2 = @NewCol2Value,
Set Col3 = @NewCol3Value
WHERE Col1 = @OldCol1Value AND
Col2 = @OldCol2Value AND
Col3 = @OldCol3Value


7) если rowsupdated = 0, то переходим на первый пункт и начинаем новую попытку, если нет, то close() и все.

или лучше тоже самое делать DataSet'ом и DataAdapter'ом?

Всмысле, мне кажется что DataReader'ом быстрее будет работать. Или нет?

Здравствуйте, CyberRussia, Вы писали:

CR>Если это тот о чем я думаю, то чтение данных и их сохранение происходит в пределах одного постбэка. Тогда алгоритм такой:

Ну да так, за один постбэк это делается все.

CR>открыть соединение с БД.
CR>создать транзакцию
CR>прочитать данные с одновременной блокировкой

Я мало знаком с транзакциями, все делал раньше просто датаридерами, не могли бы вы привести кусок кода какой-нибудь, где показано как читать данные с одновременной блокировкой. Как делается эта одновременная блокировка?

CR>провести необходимые преобразования с данными
CR>сохранить данные в БД
CR>дать подтверждение на транзакцию
CR>закрыть соединение с БД

CR>Если в это время будет стучаться кто-то другой, то будет ждать пока не освободиться запись или не сработает TimeOut.

Тут еще есть один ньюанс, кроме конкуренции за обновление записи, в это же время может быть куча запросов на получение данных, то есть просто SELECT и вывод на форму. Что будет в таком случае с пользователями (потоками) которые хотят просто прочитать заблокированную запись из таблицы? Они получат экзепшн что запись заблокирована и закончат работу или они будут ждать пока она не освободится?

Здравствуйте, stump, Вы писали:

S>Здравствуйте, Аноним, Вы писали:

А>>Еще хочу пояснение сделать следующее, мне необходимо сделать так, чтобы абсолютно все обновления записи были произведены, то есть, если в результате апдейта выяснилось, что запись уже была обновлена, необходимо я так предполагаю заново её прочитать, снова произвести те же изменения и попытаться сохранить, если опять она была обновлена кем то, то все повторяется снова. Вот самый главный вопрос, как именно такую схему лучше реализовать в ASP.NET? Я знаю что в DataSet'ах ADO.NET реализованы механизмы позволяющие использовать оптимистическую блокировку, только вот вопрос то в том, как это делать если я использую её в веб-приложении? У меня основная цель — сильно не грузить сервер. Например вот такой алгоритм пойдет или нет? :

А>>1) читаю запись из таблицы
А>>2) выполняю действия по её изменению (в коде)
А>>3) пытаюсь обновить запись в базе
А>>4) если запись была обновлена кем то еще (экзепнш) , то возврат на пункт 1)

А>>таким образом запись когда нибудь да обновится я думаю =), только вот вопрос в том, сильно ли это будет круто для сервера на котором лежит мое приложение?

S>Это уже не "оптимистическая блокировка". Это называется "кто последний тот и прав". :-\ Надо будет только как-то объяснить пользователям, куда пропадают изменения в данных сделанные ими :)

Не не, вы не поняли, пользователи не полностью обновляют данные записи, а добавляют туда свою информацию, то есть они читают сначала старую запись, потом в коде к этим данным добавляется то что ввел пользователь и потом все это сохраняется обратно в эту запись.

Здравствуйте, stump, Вы писали:

S>Здравствуйте, Аноним, Вы писали:


А>>Не не, вы не поняли, пользователи не полностью обновляют данные записи, а добавляют туда свою информацию, то есть они читают сначала старую запись, потом в коде к этим данным добавляется то что ввел пользователь и потом все это сохраняется обратно в эту запись.

S>Так старые данные затрешь при апдейте!

Почему затру? Допустим в записи есть поле Simple_Text, его первоначальное значение = "Simple text", каждый туда дописывает свое слово, ну и работает все так:

первый тип читает запись, значение = Simple text, он читает его в строковую переменную, и прибавляет слово "Вася", в итоге получается строка "Simple text Вася", потом он хочет сделать апдейт и сохранить, а ему вылетает экзепшн что запись уже обновлена, он читает её снова, а там текст уже такой "Simple text Люся", он опять дописывает туда своего васю и получается строка "Simple text Люся Вася", пробует сохранить запись обратно в таблицу, на этот раз все нормально он успел, и делается апдейт который записывает запись со строкой "Simple text Люся Вася", ну и так далее.
Вот здесь под оптимистичной блокировкой я понимаю то что Васе пришлось попробовать еще раз, потому что Люся обновила раньше него, хотя он вроде как первый был =).