Практического опыта работы с БД к сожалению нет. Из курса СУБД помню, что проблема вроде бы классическая, но вот классического решения не припоминаю. Да и в гугле ничего толкового найти не удалось как ни странно.
Опишу проблему на примере: двум пользователям отправлена страничка с одинаковыми данными. Один изменил ее и быстро отправил на сервер. А другой только через пол часа. Но вот беда, меня то он ее на основе устаревших данных и не видел, что ввел другой пользователь, данные которого потерялись.
Кто может посоветовать решение?
На вскидку думаю в хранимую процедуру обновления данных передавать старое значение и если оно совпадает с текущим, то производить обновление, если нет, то посылать пользователю сообщение обновить страницу, т.к. его данные устарели.
Приемлемое ли такое решение?
Быдлокодер wrote:
> Практического опыта работы с БД к сожалению нет. Из курса СУБД помню,
> что проблема вроде бы классическая, но вот классического решения не
> припоминаю. Да и в гугле ничего толкового найти не удалось как ни странно.
Ну да, lost update называется Он же write scqueue. Но это не совсем он, а похожая
ситуация. lost update -- это феномен (один из), в терминах которого
описываются уровни изоляции транзакций.
> Опишу проблему на примере: двум пользователям отправлена страничка с
> одинаковыми данными. Один изменил ее и быстро отправил на сервер. А
> другой только через пол часа. Но вот беда, меня то он ее на основе
> устаревших данных и не видел, что ввел другой пользователь, данные
> которого потерялись.
>
> Кто может посоветовать решение?
>
Решения два.
1) делать всё, начиная с чтения данных,
включая редактирование и сохранение в одной большой долгой
транзакции. Тогда сама СУБД сможет обнаружить конфликт и
разрешить ситуацию. Ситуация будет разрешена ОТМЕНОЙ и откатом
одной из транзакций. Проблема только в том, что транзакции
будут долгими и должны они проходить на высоком уровне
сериализации (видимо, SERIALIZABLE).
2) Использовать так называемый optimistic lock.
Заключается он в том, что ничего не блокируется, всё
в отдельных транзакциях, но при сохранении данных проверяется,
что никто до тебя данные не поменял. Это можно сделать несколькими
путями
-- по совпадению всех полей данных.
пишется
update theTable set .... where pk = @pk and field1 = @field1 and field2 =
@field2
и так далее, все поля записи (кроме PK,который и так уже есть).
@field1, @field2 ... -- естественно, изначально прочитанные из СУБД значения
полей, до изменения.
-- по полю типа timetsamp.
Аналогично предыдущему, но изменение записи контролируется только по
значению одного поля типа timetsamp. Напоминаю, что такое поле может быть
в записи только одно и оно автоматом меняется сервером при изменении записи.
(а руками его поменять нельзя)
-- комбинация первого и второго.
При обнаружении конфликта -- UPDATE при этом не изменит ни одной записи --
запись читается с сервера снова, и пользователь её должен редактировать
заново (изменения теряются).
Преимущества -- нет длинной транзакции, нет конфликтов. Недостатки --
более сложная схема сохранения данных.
> На вскидку думаю в хранимую процедуру обновления данных передавать
> старое значение и если оно совпадает с текущим, то производить
> обновление, если нет, то посылать пользователю сообщение обновить
> страницу, т.к. его данные устарели.
Ну, ты знал, ты знал.
Posted via RSDN NNTP Server 2.1 beta
avpavlov wrote:
> Всё верно, только со сравнением всех полей я бы связываться не стал.
> Потому что есть НУЛЛы, есть блобы — всё это требует специальной
> обработки, так что решение с таймстампом идеальное. А где нет
> таймстампа, там легко свой счётчик приделать.
Я бы тоже не стал.
Posted via RSDN NNTP Server 2.1 beta
Спасибо всем за участие. Особенно благодарю MasterZiv за развернутый ответ.
Тему переименовали и я просто не увидел новых сообщений
Использую rowversion, т.к. пишут, что timestamp не будет поддерживаться в будущих версиях.
http://technet.microsoft.com/ru-ru/library/ms182776(SQL.90).aspx
