Конкурентная работа в Cache

Добрый день.

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

1. Как сделать так, чтобы движок метод %Save() сохранял в БД не все свойства объектов, а только измененные в текущем сеансе? Чтобы не затирать старыми значениями конкурентные изменения других клиентов.

2. Как сделать так, чтобы движок Cache перед сохранением объекта проверял наличие конкурентных изменений в БД? Т. е. если запустить такой тест:

Два клиента считали один и тот же объект x в виде
x.p1 = "123"
x.p2 = "qwe"

Далее:
сначала на клиенте 1
set x.p1 = "cli1"
set x.p2 = "cli1"
do x.%Save()

затем на клиенте 2
set x.p2 = "cli2"
x.%Save()

В итоге в БД имеем
x.p1 = "123"
x.p2 = "cli2"

А хотелось бы, чтобы для сценария 1 получилось
x.p1 = "cli1"
x.p2 = "cli2"
а для сценария 2 второй клиент отвалился с ошибкой "запись конкурентно изменена". При этом проверки конкурентных изменений желательно делать только для измененных в текущей версии объекта полей, а не для всего объекта в целом.

Лочить записи в данном случае нельзя, так как пользователи на каждом из клиентов могут очень долго думать (читай набивать длиннющий Description), прежде чем сохранят свои изменения.

Приветствуются любые мысли по конкурентной работе в данном контексте (т. е. без локов). Больше всего интересуют мысли по поводу сценария 2.

Заранее спасибо.

а какое же будет удивление юзера, который долго набивал description а при сохранении ему вдруг стали отказывать, дескать до вас уже успели...

стандартных средств вроде нет..но можна руками.
тут смотря как у вас организована работа, но вобщем случае, думаю юзеру было бы полезно знать при открытии объекта тот факт, что объект уже открыт другим пользователем и что ему придется подождать, и например перейти в режим ReadOnly, можна даже опрашивать сервер с неким интервалом на доступность объекта и если он свободен, то переходить в режим корректирования

Лиман Артём

а какое же будет удивление юзера, который долго набивал description а при сохранении ему вдруг стали отказывать, дескать до вас уже успели...

У нас именно так. Все пользователи предупреждены и возражений от них нет.

ну я

Лиман Артём а какое же будет удивление юзера, который долго набивал description а при сохранении ему вдруг стали отказывать, дескать до вас уже успели... У нас именно так. Все пользователи предупреждены и возражений от них нет.

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

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

Лиман Артём

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

Подозревает. Их обучают тому как ведет себя программа и как им вести себя в такой ситуации.

У кого - как, а у наших пользователей лучше делать именно так. Причина в том, что они могут и на обед пойти, начать по телефону разговаривать, пойти на совещание, покурить, в туалет и вообще уйти с работы не выйдя из системы. Лучше раз в день одного посылать нафиг чем десяток каждый час.

ну я

У кого - как, а у наших пользователей лучше делать именно так. Причина в том, что они могут и на обед пойти, начать по телефону разговаривать, пойти на совещание, покурить, в туалет и вообще уйти с работы не выйдя из системы. Лучше раз в день одного посылать нафиг чем десяток каждый час.

ну для таких вещей есть таймаут простоя. Но если вам так подходит и все с этим согласны....

Лиман Артём

ну для таких вещей есть таймаут простоя. Но если вам так подходит и все с этим согласны....

Есть и такое - но у нас это разные вещи. Если таймаут кончился, то при любом обращении к базе система просит подтвердить пароль. Типа а не цереушник ли ты, пробравшийся в здание и дождавшийся когда менеджер отлучится. После подтверждения работа продолжается с того же места. Если объект больше никем не редактировался, то даст сохранить нормально как ни в чем не бывало.

Лиман Артём

стандартных средств вроде нет..но можна руками.

Я, честно говоря, не очень представляю, как это сделать руками...
Для одного объекта - понятно. Можно считать две копии объекта, а перед сохранением - еще и третью и сравнить с той, что была считана изначально.

Но как это сделать для всего графа связанных объектов? Я ведь не управляю загрузкой этих объектов... Может, можно перекрыть какие-то методы класса %Pesistent, чтобы реализовать необходимое мне поведение?

Вообще-то я новичок в Каше и мне нужно понять, использовать его объектную модель или писать свою и работать на уровне Cache Direct. Пока только одна принципиальная проблема: не знаю как организовать конкурентный доступ в требуемом виде.

Не понял, как такое возможно - перписывание обновленного объекта.
Куда версионность и блокировки смотрят ?