Совместное использование одной таблицы

← →
DeadMeat © (2006-11-20 16:57) [0]

Здравствуйте.
Я в базах новичек, поэтому сильно не бейте (хотя бы не ногами).
Есть:

СУБД Microsoft SQL 2000 (SP3)
ADO (компоненты ADOConnection и ADODataSet)
EhLib (компоненты MemTableEh и DBGridEh)
Таблица (просто список людей)
Несколько пользователей (работники)

Надо:

При совместной работе с одной таблицей двух и более пользователей разруливать ситуацию с обновлением информации.

Понимаю, что сказал бред. Попробую пояснить.
Допустим пользователь ЮЗЕР1 выбрал первую запись для редактирования (первая - это образно, первая сверху). Отредактировал и сохранил обратно в базу (MemTableEh.Edit, MemTableEh.Post, MemTableEh.ApplyUpdates(0)). Если после этого пользователь ЮЗЕР2 решит отредактировать эту же запись, то выскочит ошибка "Не удается найти строку для обновления.......". Погуглив выяснилось, что проблема в том, что после редактирования найти эту запись ЮЗЕР2 уже не может, т.к. критерии поиска уже другие. Соответственно
введя первичный ключ и добавив в AfterOpen задание параметра Update Criteria значением adCriteriaKey проблема решается. Но лишь проблема появления ошибки. Т.е. получается, что ЮЗЕР2 не видя то, что записал в базу ЮЗЕР1 запишет туда что-нить свое. А вот хотелось бы отобразить изменения, которые сделал ЮЗЕР1 для всех остальных пользователей. Вводить дополнительно сетевую часть (передавать всем броадкастом информацию об обновлениях) не очень хочется. Каждый раз делать Requery перед редактированием любой записи тоже. Может есть способ еще? Как определить, что "вот эту" запись изменили, и что "вот эту" запись надо обновить? Пробовал проверять RecordStatus на rsModified - не помогло.

ЗЫ. Вполне вероятно, что гдето написал бред, но я только начал эту область осваивать.

ЗЗЫЫ. Пишу в BDS2006.

← →
Sergey13 © (2006-11-20 17:01) [1]

А при чем тут MemTableEh? Какова ее роль?

Вопрос об обновлении данных, отредактированных другим юзером, обсуждается каждую неделю. Каждый раз это признается бессмысленной тратой ресурсов в 99.9% случаев.

← →
clickmaker © (2006-11-20 17:02) [2]

> DeadMeat © (20.11.06 16:57)

Знакомая проблема, ага.
Но решений, увы, кот наплакал. Ты их практически почти перечислил. Т.е. либо есть некий сервис, который оповещает остальных, что некто Вася поменял запись 1. После 2 варианта. Либо переоткрытие датасета, либо вообще не используется грид, а например ListView. Тогда можно индивидуально управлять записями по ID.
Еще вариант, если записей не слишком много, и жесткий риалтайм не нужен, то по таймеру обновлять табличку на клиенте.

← →
clickmaker © (2006-11-20 17:05) [3]

Для особо критичных данных иногда применяют следующее. Грид редактировать запрещают вообще. Только специальной формой. При открытии формы запись блокируется. Все остальные после этого получают либо отлуп, либо предложение открыть инфу для чтения. Эта идея с успехом используется в офисных приложениях (ворд, эксель).
Форма закрылась - блокировку снимаешь

← →
DeadMeat © (2006-11-20 17:38) [4]

> Sergey13 © (20.11.06 17:01) [1]
> А при чем тут MemTableEh? Какова ее роль?

Он для "нормального" отображение данных в DBGridEh. Сортировка, отображение денег, пропорциональная полоса прокрутки ну и еще там по мелочи. С ним проще мне кажется.

> clickmaker © (20.11.06 17:05) [3]
> Для особо критичных данных иногда применяют следующее. Грид
> редактировать запрещают вообще. Только специальной формой.
> При открытии формы запись блокируется. Все остальные после
> этого получают либо отлуп, либо предложение открыть инфу
> для чтения. Эта идея с успехом используется в офисных приложениях
> (ворд, эксель).Форма закрылась - блокировку снимаешь

Ну собсна у меня данные как раз отдельной формой и редактируются. Вот только вопрос как без этого дополнительного сервиса заблокировать запись, чтобы ЮЗЕРх это "понял". Т.е. как другим пользователям "объяснить", что "вот эта" запись заблокирована. Думаю осуществив этот механизм, можно сделать обновление именно "этой" записи после снятия блокировки.

В любом случае, благодарю за ответы.... Если есть еще мысли - буду рад.

← →
clickmaker © (2006-11-20 17:42) [5]

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

поле завести в таблице. Типа user_id или session_id или вообще spid (зависит, как у вас там работа с пользователями)
Если оно не нулевое, значит запись занята

← →
DeadMeat © (2006-11-20 23:16) [6]

> clickmaker © (20.11.06 17:42) [5]
> поле завести в таблице. Типа user_id или session_id
> или вообще spid (зависит, как у вас там работа с пользователями)Если
> оно не нулевое, значит запись занята

А... Другими словами все надо делать ручками. Понятно. Я просто думал есть какие способо через методы/свойства ADO и самого MSSQL. Но по всей видимости быстрее и проще всего будет руками все организовать.
Ну чтож... раз другого выхода нет - будем делать так.
Большое спасибо за информацию...

← →
Kolan © (2006-11-20 23:22) [7]

Я тоже новичок в бд, но разве это не забота сервера разрулить ситуацию?

← →
DeadMeat © (2006-11-20 23:29) [8]

> clickmaker © (20.11.06 17:42) [5]
> поле завести в таблице.

Или я просто под вечер не соображаю или что. Но вот щас подумал и вопрос возник.
Вот заведу я это поле в таблице. Каждая запись будет иметь еще одно дополнительное поле. ЮЗЕР1 открыл запись для редактирования. Перед этим записали в это поле 1 (например). Как ЮЗЕР2 сможет считать значение этого поля, когда оно изменилось? Опять же вопрос про обновление данных. Целиком обновлять или как? Или просто завести отдельную таблицу не большого размера и в ней хранить запись типа:
TableName | RecordNum --------------------- TABLE1 | 1 TABLE2 | 3
Смысл в том, что таблица не большая и вполне можно (хотя мне и не нравится такой способ) делать Requery или даже закрывать и открывать по новой датасет.

Что посоветуете?

← →
ЮЮ © (2006-11-21 04:04) [9]

> Таблица (просто список людей)
> Несколько пользователей (работники)

Как вообще возникает ситуация, что 2 разных работника пытаются одновременно ввести совершенно разную информацияю для просто человека? Даже если они не пересекутся по времени, то информация с точки зрения одного из работников будет неверная.

← →
DeadMeat © (2006-11-21 08:38) [10]

> ЮЮ © (21.11.06 04:04) [9]

Ну тут несколько иначе. ЮЗЕР1 сделал запись. Посидели... поболтали. Тут ЮЗЕР1 просит ЮЗЕР2 сделать еще изменения, которые он забыл сделать. А просит, потому что ему надо выйти. Ну просто попросил. Вот и явный пример. Это только один пример. Но основная проблема тут в принципе в том, чтобы отобразить сделанные изменения.

← →
Sergey13 © (2006-11-21 08:58) [11]

> [10] DeadMeat © (21.11.06 08:38)

А EhLib у тебя какая? Щас почитал про 4, там вроде МемТабл - это практически некий аналог CDS, раньше вроде был попроще (но и с тем я не работал 8-). Т.е. непонятно как (механизм) изменяется база.
Плюс к этому, почему после изменения одним юзером другой не может изменить ту же запись? Первичный ключ меняется что-ли? Если запись просто изменена и не закомичена, то должно вроде бы другое сообщение вылезти (типа: запись была изменена другим пользователем).

← →
DeadMeat © (2006-11-21 09:57) [12]

> Sergey13 © (21.11.06 08:58) [11]

EhLib 4.1 Build 4.1.4 Russian version
Когда покупал на тот момент была последней (покупал не давно).

> Плюс к этому, почему после изменения одним юзером другой
> не может изменить ту же запись?

Сейчас ЮЗЕР2 может изменить запись, скорректированную ЮЗЕР1. Update Criteria равный adCriteriaKey и первичный ключ спасли. Без этого было только то сообщение, которое я привел ("Не удается найти строку для обновления......."), ведь ЮЗЕР2 уже не может найти ту запись, т.к. без ключа поиск можно было сделать лишь по другим полям, а они уже изменились. Почему не выдавалось другого сообщения - я не знаю.

По поводу механизма, могу лишь сказать, что все изменения (как я понял) отсылаются в DataSetDriverEh скопом (после ApplyUpdates), который затем отслыает их в ADODataSet. Хотя конечно могу и ошибаться. В моем случае, я включил CachedUpdates и FetchAllOnOpen. Т.е. все данные я забираю в память целиком, а не кусками выкачиваю с сервера. Просто на стадии разработки не хотелось заморачиваться с "подкачкой" данных. Мне казалось, что проще пока будет все отладить так, а потом уже (при надобности) делать "подкачку" с сервера порциями. Да и в принципе, основной причиной выбора MemTableEh в связке между DBGridEh и ADODataSet был пропорциональный ScrollBar (вертикальный). Почему то без него я этого добиться не смог.

← →
clickmaker © (2006-11-21 09:59) [13]

> [8] DeadMeat © (20.11.06 23:29)
> Вот заведу я это поле в таблице. Каждая запись будет иметь
> еще одно дополнительное поле. ЮЗЕР1 открыл запись для редактирования.
> Перед этим записали в это поле 1 (например). Как ЮЗЕР2 сможет
> считать значение этого поля, когда оно изменилось?

Ну как... юзер1 поменял что-то, нажал ОК. Запись закоммитилась, блокировку сняли. Теперь она доступна другим, уже с измененными данными.
Другое дело - это оповещение об изменении. Тут уже зависит от критичности по времени.
В билетной системе я делал обновление схемы зала по таймеру. Интервал выбирает пользователь, а может вообще выключить. Но тогда при попытке продать уже занятое место просто вылезет сообщение.

← →
Sergey13 © (2006-11-21 10:06) [14]

> [12] DeadMeat © (21.11.06 09:57)

> Да и в принципе, основной причиной выбора MemTableEh в связке
> между DBGridEh и ADODataSet был пропорциональный ScrollBar
> (вертикальный). Почему то без него я этого добиться не смог.

Скорее всего нужно было закачать все данные возвращаемые запросом на клиента. Т.е. сделать ADODastaSet.Last (или что-то вроде этого - я с АДО не работал). Плюс у гридовского скролбара Tracking выставить в истину.

← →
DeadMeat © (2006-11-21 10:53) [15]

> clickmaker © (21.11.06 09:59) [13]

Общую схему я понял. Встает вопрос об обновлении несколько в другом смысле. Получается, что обновление надо будет все таки делать по таймеру. Это ладно. Смиримся. Вынесем в настройки. Но вот как после обновления попросить сервер вернуть только одну эту измененную запись, а не весь набор целиком?

> Sergey13 © (21.11.06 10:06) [14]

Хмм... Спасибо. Учту. Надо будет проверить. Может нужда в EhLib отпадет и вовсе.

← →
clickmaker © (2006-11-21 11:02) [16]

> Но вот как после обновления попросить сервер вернуть только
> одну эту измененную запись, а не весь набор целиком?

Теоретически можно завести некий сервис для оповещения. Клиент, обновивший запись шлет ему сообщение, что мол обновил запись с ID=233, а сам сервер рассылает его подключенным клиентам.
Но тогда клиент должен отдельным запросом получить только одну эту запись и обновить какой либо список. Грид же обновляется только целиком, поскольку сам он списка не содержит, а просто отображает датасет.
Т.е. нужен датасет, в котором можно поменять 1 запись. Например, датасет в памяти.

← →
Bless © (2006-11-21 15:52) [17]

> Но вот как после обновления попросить сервер вернуть только
> одну эту измененную запись, а не весь набор целиком?
>

Как-то давно, на этом форуме давали пример:

var q:TCustomADODataset; ... //обновить текущую запись датасета q q.UpdateCursorPos; q.Recordset.Resync(adAffectCurrent,adResyncAllValues); q.Resync([rmExact]); ...

Чтобы обновление работало, как ожидается, возможно, также понадобится настроить ADODataSet1.Properties["Resync Command"].Value

← →
Bless © (2006-11-21 15:54) [18]

> ADODataSet1.Properties["Resync Command"].Value

q.Properties["Resync Command"].Value конечно же

← →
DeadMeat © (2006-11-22 16:25) [19]

Спасибо всем ответившим.
Проблему решил так:
1. Обновление всего списка по таймеру или по кнопке в зависимости от настроек.
2. Обновление текущей записи прямо перед открытием ее для редактирования.

Пункт 1 пришлось ввести из-за того, что пользователей не 2, а больше и изменять они могут сразу несколько записей (каждый свою), поэтому приходится обновлять весь список.
ИМХО, нужда в отдельном сервисе появится в том случае, если количество записей перевалит за предел, в результате которого время обновления увеличится секунд так до 5-6. И то, можно обойтись без этого используя подкачку. Обновлять только те записи, на которые сейчас смотрит пользователь. Думаю этого должно хватить...

Спасибо еще раз за советы... Вы мне очень помогли.

ЗЫ. После некоторых поисков по исходникам EhLib нашел тоже самое - обновление только одной записи. Поэтому пока что останусь на нем.

← →
MsGuns © (2006-11-22 20:27) [20]

>clickmaker © (20.11.06 17:02) [2]
>Знакомая проблема, ага.
>Но решений, увы, кот наплакал.
(Дальше не привожу, ибо уже полный бред)

+

>clickmaker © (21.11.06 09:59) [13]
>Ну как... юзер1 поменял что-то, нажал ОК. Запись закоммитилась, блокировку сняли. Теперь она доступна другим, уже с измененными данными.

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

Я извиняюсь перед Мастером, но все же задам 2 вопроса:

1) Вы знакомы с понятием "транзакции" и "взаимовлияние транзакций" ?
и
2) в какой это предметной области Вы городите всю эту чушь ?

ЗЫ. Обратите все же внимание на пост [9]

← →
MsGuns © (2006-11-22 20:30) [21]

>DeadMeat © (22.11.06 16:25) [19]
>Проблему решил так:
>1. Обновление всего списка по таймеру или по кнопке в зависимости от настроек.

Не делайте этого !

>2. Обновление текущей записи прямо перед открытием ее для редактирования.

Это ничего Вам не даст в плане актуальности этой самой записи.

← →
clickmaker © (2006-11-23 09:49) [22]

> >clickmaker © (21.11.06 09:59) [13]
> >Ну как... юзер1 поменял что-то, нажал ОК. Запись закоммитилась,
> блокировку сняли. Теперь она доступна другим, уже с измененными
> данными.
>
> Если дом построить на трясине, то, действительно, потом
> придется прилагать гигантские усилия, чтобы он не рухнул
> и не уплыл..
>
> Я извиняюсь перед Мастером, но все же задам 2 вопроса:
>
> 1) Вы знакомы с понятием "транзакции" и "взаимовлияние транзакций"
> ?
> и
> 2) в какой это предметной области Вы городите всю эту чушь
> ?

причем тут транзакции?
простой пример: есть заказ. Есть 2 кассира, которые могут его поменять. Например, согласно пожеланию клиента. Если один кассир его откроет и начнет долго и мучительно выяснять у клиента, а что собственно он хочет, то о каких вообще транзакциях и уровнях их блокировок может идти речь?
При этом второй кассир ВООБЩЕ не должен иметь доступ на запись к этому заказу. Надеюсь, понимаете, почему.
Вот такая вот предметная область.
Если у Вас есть решение лучше, чем блокировка на запись с помощью доп. поля - готов выслушать

← →
Anatoly Podgoretsky © (2006-11-23 09:56) [23]

> clickmaker (23.11.2006 09:49:22) [22]

Есть - это резервирование

← →
clickmaker © (2006-11-23 10:03) [24]

> [23] Anatoly Podgoretsky © (23.11.06 09:56)
> > clickmaker (23.11.2006 09:49:22) [22]
>
> Есть - это резервирование

?

← →
Anatoly Podgoretsky © (2006-11-23 10:06) [25]

> clickmaker (23.11.2006 10:03:24) [24]

Запись не блокировать, а резервировать для операции, стандартное решение для кассиров.
Сначала запись резервируется, потом редактируется, потом в или возращается из резерва или операция завершается нормально.
Всегда известно, кто и когда и никаких конфликтов и блокировок.

← →
clickmaker © (2006-11-23 10:10) [26]

> [25] Anatoly Podgoretsky © (23.11.06 10:06)
> > clickmaker (23.11.2006 10:03:24) [24]
>
> Запись не блокировать, а резервировать для операции, стандартное
> решение для кассиров.
> Сначала запись резервируется, потом редактируется, потом
> в или возращается из резерва или операция завершается нормально

а я что предлагал?
Или я чего-то не понял, или мы просто разные термины пользуем

← →
clickmaker © (2006-11-23 10:17) [27]

> Сначала запись резервируется

update Orders set LockUser_ID = User_ID -- перед открытием заказа кассиром User_ID

> потом редактируется

update Orders set что-то where Order_ID = @OrderId

> возращается из резерва

update Orders set LockUser_ID = null where Order_ID = @OrderId

или я опять "полный бред" пишу?

← →
clickmaker © (2006-11-23 10:19) [28]

Забыл добавить. Если кто-то другой попытается открыть заказ
if (LockUser_ID IS NOT NULL)
"Заказ уже редактируется пользователем LockUser_ID. Можете открыть только для чтения"

чем не решение?

← →
ANB © (2006-11-23 10:30) [29]

Автору - у тебя уже все готово практически.
Надо только добавить следующую фичу :
Перед редактированием (подъемом формы на редактирование) нужно изменяемую запись перечитать с блокировкой.
Решится 2 задачи :
а) в форме будут свежие данные
б) сервером запись будет заблокирована и другой юзер ее открыть не сможет (тут возможны вариации с предложением открыть на чтение, обработав ошибку).
в оракле это делается элементарно : select for update
в мс скл должна быть подобная фича (где то я про нее читал).
К сожалению, я не нашел в ADO метода для рефреша одной записи да еще и с блокировкой, в ОДАКЕ это сделано явно, там и запрос настроить ручками можно. Впрочем, ща спецы придут - подскажут.
Если никак - то можно редактировать не основной набор данных, а свежезачитанный (надеюсь искусственные ключи в таблицах есть). А так как гридовые данные все равно в локальной кэше сидят, то сможешь изгальнуться обновить их, не отправляя на сервер.

← →
ANB © (2006-11-23 10:33) [30]

ИМХО : изобретать велосипед с блокировкой через доп.поле - вчерашний век. У этого метода есть целая куча минусов.
Оправдана работа только с резервированием, но это совсем другая тема.

← →
clickmaker © (2006-11-23 10:35) [31]

> [30] ANB © (23.11.06 10:33)
> ИМХО : изобретать велосипед с блокировкой через доп.поле
> - вчерашний век. У этого метода есть целая куча минусов.
> Оправдана работа только с резервированием

каких минусов?

и растолкуйте мне тупому, что же это за магическое резервирование такое?
Может снизойдет на меня просветление

← →
ANB © (2006-11-23 11:01) [32]

> каких минусов?
>
> и растолкуйте мне тупому, что же это за магическое резервирование
> такое?
> Может снизойдет на меня просветление

Самые элементарные минусы :
1) пока транзакцию, меняющую это поле на статус "Заблокировано" не закоммитишь, никто этой блокированности не увидит. Сие может привести к одновременной "Блокировке" двумя и более пользователями.
2) В случае сваливания клиента/сервера "блокированные" записи так такими и остануться. Значит придется изобретать всякие хитрые кнопки по аварийному разблокированию, которыми начнут пользоваться не по назначению и т.д.
Короче, я этот способ уже юзал - он довольно простой на первый взгляд, но грабли я все собрал :) Учись на моих ошибках :)
Ликбез по резервированию :
Возьмем для примера склад.
Есть остаток товара на складе, в минус его загонять нельзя. Несколько операторов шпандорят накладные. Есно, нельзя допустить, чтобы товара выписали больше, чем на складе. Чтобы этого не допустить, когда вводишь строку с товаром, запрошенное количество от отстатка минусуется и переводится в резерв (есть несколько способов реализации - тута можно поспорить). Далее готовую накладную можно либо провести, либо откатить нафиг. В первом случае резерв просто минусуется, во втором - резерв приплюсовывается обратно к остатку.
Нечто подобное реализуется и при работе билетного кассира - там места имеют несколько статусов - свободно, резерв, продано. При заказе билета они сначала резервируются, чтобы другой кассир не мог продать, а уже при их оформлении продаются. Резерв можно вернуть обратно в свободные при отказе от покупки билета или если кассир заснул. Перед продажей, есно проверяется, находится ли место в статусе резерв за этим кассиром.

← →
Anatoly Podgoretsky © (2006-11-23 11:07) [33]

> clickmaker (23.11.2006 10:10:26) [26]

Я не знаю, что ты предлагал, только термин блокировка по отношению к базам имеет одназначное толкование.

← →
Anatoly Podgoretsky © (2006-11-23 11:07) [34]

> clickmaker (23.11.2006 10:17:27) [27]

Вот это блокировка и есть

← →
Anatoly Podgoretsky © (2006-11-23 11:08) [35]

> clickmaker (23.11.2006 10:19:28) [28]

Это тоже блокировка, да и название говорит об этом.

← →
Anatoly Podgoretsky © (2006-11-23 11:09) [36]

> clickmaker (23.11.2006 10:35:31) [31]

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

← →
clickmaker © (2006-11-23 11:13) [37]

> При заказе билета они сначала резервируются, чтобы другой
> кассир не мог продать, а уже при их оформлении продаются.
> Резерв можно вернуть обратно в свободные при отказе от покупки
> билета или если кассир заснул. Перед продажей, есно проверяется,
> находится ли место в статусе резерв за этим кассиром

совершенно верно. Так и делал. У поля есть статусы "свободно", "занято", "продано". И можно узнать, кто конкретно в процессе его продажи находится.
Но меня интересует именно глубинный механизм. Что, есть для этого какие-то встроенные средства SQL? И к тому же не зависящие от СУБД

> пока транзакцию, меняющую это поле на статус "Заблокировано"
> не закоммитишь, никто этой блокированности не увидит. Сие
> может привести к одновременной "Блокировке" двумя и более
> пользователями

для этого есть хинт holdlock

← →
clickmaker © (2006-11-23 11:15) [38]

> [36] Anatoly Podgoretsky © (23.11.06 11:09)
> > clickmaker (23.11.2006 10:35:31) [31]
>
> У блокировок обычный минус - всем хана, даже некоторые аггрегатные
> функции не сможешь выполнить

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

← →
ANB © (2006-11-23 11:25) [39]

> clickmaker © (23.11.06 11:15) [38]

Переходи на оракл :) В нем проблем с родными серверными блокировками нету - все функции нормально работают, только еще раз заблокировать не даст. Плюс есть еще юзеровые блокировки, вообще гибкая вещь.

← →
clickmaker © (2006-11-23 11:30) [40]

> когда вводишь строку с товаром, запрошенное количество от
> отстатка минусуется и переводится в резерв (есть несколько
> способов реализации - тута можно поспорить). Далее готовую
> накладную можно либо провести, либо откатить нафиг. В первом
> случае резерв просто минусуется, во втором - резерв приплюсовывается
> обратно к остатку

а как в данном случае разруливается эта ситуация:

> В случае сваливания клиента/сервера "блокированные" записи
> так такими и остануться

← →
Anatoly Podgoretsky © (2006-11-23 11:44) [41]

> clickmaker (23.11.2006 11:30:40) [40]

С трудом разруливается.

← →
clickmaker © (2006-11-23 11:49) [42]

> [41] Anatoly Podgoretsky © (23.11.06 11:44)
> > clickmaker (23.11.2006 11:30:40) [40]
>
> С трудом разруливается.

в таком случае, не понимаю, чем предложенный мной вариант резервирования хуже?
И что все-таки вы имеете в виду под "резервированием"?

← →
ANB © (2006-11-23 12:08) [43]

> в таком случае, не понимаю, чем предложенный мной вариант
> резервирования хуже?

Резервирование несколько глючнее родных блокировок. К тому же я не въезжаю - зачем оно в данном случае нужно - задача стоит :
а) не давать редактировать одну запись одновременно двум юзерам
б) перед редактированием иметь свежие данные.
Это легче и надежнее всего таки на серверных блокировках разрулить.
Случай с резервированием требует наличия "служебных" кнопок для аварийного разрезервирования, что не очень кузяво. (В одной конторе на этой кнопке скорая помощь на иконке была :) )

← →
clickmaker © (2006-11-23 12:11) [44]

> Случай с резервированием требует наличия "служебных" кнопок
> для аварийного разрезервирования, что не очень кузяво

достаточно некоего сервиса, который сам за этим следить будет

> Это легче и надежнее всего таки на серверных блокировках
> разрулить

а как узнать, кто именно взял запись и держит?

← →
Anatoly Podgoretsky © (2006-11-23 12:12) [45]

> clickmaker (23.11.2006 11:49:42) [42]

Подразумевается только резервирование и ничего больше.

← →
Anatoly Podgoretsky © (2006-11-23 12:45) [46]

> ANB (23.11.2006 12:08:43) [43]

> а) не давать редактировать одну запись одновременно двум юзерам

Не давать расходовать в отрицательную сторону. А не про монопольное использование записи.

← →
ANB © (2006-11-23 13:13) [47]

> а как узнать, кто именно взял запись и держит?

+ юзеровая блокировка - туда можно всю инфу класть. а в простейшем случае эта инфа и не нужна.

← →
Anatoly Podgoretsky © (2006-11-23 13:37) [48]

> ANB © (23.11.06 13:13) [47]

Не пытайся переносить методы и правила Оракла на другие базы.

← →
clickmaker © (2006-11-23 13:39) [49]

> [48] Anatoly Podgoretsky © (23.11.06 13:37)
> > ANB © (23.11.06 13:13) [47]
>
> Не пытайся переносить методы и правила Оракла на другие
> базы

вот и я про то же.
Когда я подобную байду делал, у меня был сначала Sybase, а потом MS SQL. Поэтому хочется как можно более независимых решений

← →
Anatoly Podgoretsky © (2006-11-23 13:43) [50]

> clickmaker (23.11.2006 13:39:49) [49]

Надо бы сначала разобраться с предметной областью, а то мы тут копья ломаем.
Тем более вопрос несколько раз менялся и в первоначальной постановке давно решен.

← →
ANB © (2006-11-23 13:48) [51]

> Поэтому хочется как можно более независимых решений

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

ИМХО еще имхестее :) Выкинь на фиг мс скл, поставь оракл и наслаждайся :)

← →
Anatoly Podgoretsky © (2006-11-23 13:52) [52]

> ANB (23.11.2006 13:48:51) [51]

А может, ну его нафиг этот Оракл, нам пальцы крутить ни к чему :)

← →
clickmaker © (2006-11-23 14:01) [53]

> [50] Anatoly Podgoretsky © (23.11.06 13:43)
> > clickmaker (23.11.2006 13:39:49) [49]
>
> Надо бы сначала разобраться с предметной областью, а то
> мы тут копья ломаем.

да меня возмутил просто наезд г-на MsGuns.
Ничем не обоснованный, кстати. И без любого намека на конструктивизм. Дескать, "я не знаю, как делать, но так - неправильно"

← →
ANB © (2006-11-23 14:01) [54]

> А может, ну его нафиг этот Оракл, нам пальцы крутить ни
> к чему :)

Не, оракл - это кусок хлеба с маслом. С тех пор, как я на него сел, еще ни разу больше месяца, при необходимости, работу не искал :) И каждый раз находил с повышением зарплаты :)

← →
Anatoly Podgoretsky © (2006-11-23 14:06) [55]

> ANB (23.11.2006 14:01:54) [54]

С этой стороны, я с тобой полностью согласен, но тогда есть еще более масляные куски, например R/2

← →
ANB © (2006-11-23 14:15) [56]

> например R/2

Во, млин. Я такого не слышал даже - чего это ?

← →
MsGuns © (2006-11-23 14:32) [57]

>clickmaker © (23.11.06 14:01) [53]
>да меня возмутил просто наезд г-на MsGuns.
Ничем не обоснованный, кстати. И без любого намека на конструктивизм. Дескать, "я не знаю, как делать, но так - неправильно"

Чем же возмутил ? Если новичок несет ерунду из-за непонимания єлементарных вещей, то "наезды" на него наездами не считаюстя, а если непонимание механизма обмена данными в технологии "клиент-сервер" денонстрирует Мастер, то всем "стоять бояться" ?

Да, знаю. Как и многие здесь. Которые пытаются Вам объяснить, но Вы упорно стоИте на своих "блокировках". И не хотите признать всю чудовищную неуклюжесть своих приемов. Случай с кассирами далеко не самый сложный конфликт, который приходится решать в конкурентных технологиях. Та же система "Опердень" для банков или резервирование в транспорте или гостинницах куда похитрее будет. Однако никаких блокировок в них нет, да и нормальные сиквель-сервера "не знают" ни про какие "блокировки" - это термин из позавчераших локальных технологий.

Если все же обидел, готов принести извинение. Хотя мастерства Вам это вряд ли добавит

← →
clickmaker © (2006-11-23 14:36) [58]

> [57] MsGuns © (23.11.06 14:32)

да что вы прицепились к мастерству. Я значок не просил, могу вернуть.
Мне интересно, чем не устраивает мое решение проблемы? И какие оные есть в "нормальныx сиквель-сервера". И что такое "нормальный сиквель-сервер". Оракл? Ну тогда я правда пас, извините...

← →
ANB © (2006-11-23 14:49) [59]

> система "Опердень" для банков

Да, эт точно. С августа на ней сижу и еще толком не разобрался, как она работает.

← →
clickmaker © (2006-11-23 14:50) [60]

> [59] ANB © (23.11.06 14:49)
>
> > система "Опердень" для банков
>
> Да, эт точно. С августа на ней сижу

а она реально так и называется?

← →
Jeer © (2006-11-23 14:51) [61]

clickmaker © (23.11.06 14:36) [58]

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

И приходится отделять "мух от котлет" - есть вещи связанные с логико-физическим или бизнес-взаимодействием пользователей.
Когда это раскладывается по полочкам - многое проясняется.

Кроме того, сервера СУБД тоже накладывают свое видение этих процессов: есть блокировочники, есть многоверсионники..

← →
Jeer © (2006-11-23 14:52) [62]

> clickmaker © (23.11.06 14:50) [60]

Так и называется:)

Я ее "прошел" в Сбербанке - 5 лет:)

← →
clickmaker © (2006-11-23 15:01) [63]

> [61] Jeer © (23.11.06 14:51)
> clickmaker © (23.11.06 14:36) [58]
>
> Ты не горячись.
> Переход с файл-серверных технологий (а многие из тутошних
> через них прошли) на клиент-серверные технологии не должен
> вслепую сопровождаться переносом таковых из первых во вторые
> - разные это миры, разные

а я чего? я ничего. Я предложил один из вариантов, с которым сам работал когда-то. Вполне рабочий вариант. И он реально работает.
Ну не знаю я, как еще можно заблокировать место на схеме зала, чтобы его никто не смог выделить и чтобы при этом не использовать доп. поле. И какие могут быть варианты оповещения других пользователей, кроме как сообщением через промежуточный сервис, либо периодическим опросом с их стороны.
Ну так я здесь и не один. Вот MsGuns пришел и разнес меня. Правда, взамен ничего не предложил.

← →
Anatoly Podgoretsky © (2006-11-23 15:05) [64]

> ANB (23.11.2006 14:15:56) [56]

Может R3 по памяти говорю, а она иногда подводит.
Мощная система, сталкивался с ней, Оракл в ней на нижнем звене. Зарплаты по Норвегии начинаются с 6000 для свежеиспеченого выпускника ВУЗА, если он хотя умеет в ней формы делать. Система очень известная, одна из мировых систем, для построения многозвенных приложений по низкоскоростным сетям.

← →
Jeer © (2006-11-23 15:20) [65]

R3 у Ingres, DB2 у IBM, кстати за Oracle и MS тоже выпустила бесплатную версию
DB2 Express-C.

← →
Anatoly Podgoretsky © (2006-11-23 15:47) [66]

> Jeer (23.11.2006 15:20:05) [65]

Я не про базу R3, а про систему, базу как раз любую можно использовать, да и базу R3 они не так давно разработали. Я работал (как пользователь) с этой системой, сервер расположен в Копенгагене, канал 64/128 кб, печатать можно на любой принтер, хоть в Китае.
На месте только SDK (200 mb) даже формы на сервере. Время реакции типовое 0,5 секунды от запроса до появление формы. Формы кривые, смотреть страшно. Но интересно сделал один запрос одна форма, делаешь запрос повторно, уже другая форма.
Заведение учетной записи 1000 долларов, изменение формы значительно больше. Каждый филиал должен самостоятельно все оплачивать. Оттуда и информация об зарплате.

← →
Павел Калугин © (2006-11-23 15:58) [67]

> [66] Anatoly Podgoretsky © (23.11.06 15:47)

это про SAP R3?
ну да, это флаг....

← →
Jeer © (2006-11-23 16:32) [68]

> Anatoly Podgoretsky © (23.11.06 15:47) [66]

Я в свое время пытался в Сбербанке что-то подобное внедрить.
Сервера Motorola, OC AIX, у клиента только X Terminal под Windows.
Формы выглядят по разному в зависимости от допуска рабочего места.
Безопасность по максимуму:)

← →
Anatoly Podgoretsky © (2006-11-23 16:36) [69]

> Павел Калугин (23.11.2006 15:58:07) [67]

Ну вот, как только назвал это, так я и тоже вспомнил. У них есть и своя БД для него SAP DB
Но они не привязаны а БД, чаще всего используется Оракл.
Так если они такие деньги платят разработчику форм, то сколько же они платят тому кто работает с Оракл в этой системе.

Вот тут уже точно масла для хлеба хватит.

← →
Anatoly Podgoretsky © (2006-11-23 16:37) [70]

> Jeer (23.11.2006 16:32:08) [68]

Не только безопасности, но и разработка делается в одном месте, а сопровождение на местах сводится к нулю, Сумей только установить систему. Часто забывают сообщить ИП адреса серверов, как в моем случае.

← →
MsGuns © (2006-11-23 21:08) [71]

>clickmaker © (23.11.06 15:01) [63]
>Вполне рабочий вариант. И он реально работает.

У меня есть несколько систем на парадоксе 3.5 в ДОСе. Все работают до сих пор. И что ?

>Ну не знаю я, как еще можно заблокировать место на схеме зала, чтобы его никто не смог выделить и чтобы при этом не использовать доп. поле. И какие могут быть варианты оповещения других пользователей, кроме как сообщением через промежуточный сервис, либо периодическим опросом с их стороны.

Вы поймите, что Ваша самая основная "консерваторская" ошибка именно в этом магическом слове "блокировка".
И уясните еще одну простую весчь:

НИ ОДИН СЕРВЕР НИКОГДА НИКОГО И НИ О ЧЕМ НЕ ОБЯЗАН УВЕДОМЛЯТЬ.
Ну не для этого он создан ! Это все равно, что если автодорожники задумают ремонт в районе, допустим, Невского, и озадачатся оповестить всех владельцев авто, гостей города, транзитников, а кроме того всех, кто может в это время проехать по этой части города на общественном или ином транспорте как пассажир.
Просто поставьте себя на место автодорожников и Вам примерно будет понятна логика сервера, которому "до фени" проблемы одного конкретного клиента, как бы "крут" он ни был.
Лично для меня очень большую ясность в этом вопросе в свое время внесли книги Востикова и Ковязина. Хотя там речь идет об Interbase, однако соль клиент-серверного подхода к решению конфликтов в "базовых" проблемах изложена ясно и доступно. Советую Вам почитать. Ключевое слово "транзакция".

>Вот MsGuns пришел и разнес меня.

;) Это разве "разнес" ? Видели бы Вы, какую котлету тут делали из меня аксакалы лет 5 назад, когда я с пеной у рта доказывал всем какие они "дураки", что недооценивают парадокс, дибэйз и т.д. ;)))

>Правда, взамен ничего не предложил.

Что можно предложить человеку, упорно мастерящему крылья из песка и алебастра ?

← →
DeadMeat © (2006-11-24 09:03) [72]

Ох.... Не думал, что такой вопрос может вызвать подобный резонанс.
Читаю вас тут с удовольствием. Как я сказал, я новичек, а тут более-менее опыту прибавляется.
Пришел к выводу, что в данном конкретном случае есть два "простых" выхода. Делать подкачку, обновляя только видимую часть записей с запасом (без кеширования) и обновлять запись перед редактированием. Т.е. когда пользователь открыл запись на редактирование, в форме уже обновленная информация (кстати, а почему "Это ничего Вам не даст в плане актуальности этой самой записи" ? [21]). Ну, а второй выход - не делать вообще ничего. Просто не отображать изменения. Это из простых вариантов.
Осталось решить с чуть более сложными.
Резервирование говорите....
Вообщем если я правильно понял, то все проблемы опять сводятся к одной. Обновить инфу с сервера. Следовательно, нужно решить как это сделать более оптимальным способом.

← →
Anatoly Podgoretsky © (2006-11-24 09:08) [73]

> DeadMeat (24.11.2006 09:03:12) [72]

> а почему "Это ничего Вам не даст в плане актуальности этой самой записи" ?

Уже пока информация едет с сервера к тебе на компьютер, она может стать неактуальный

← →
Sergey13 © (2006-11-24 09:10) [74]

> [72] DeadMeat © (24.11.06 09:03)
> Вообщем если я правильно понял, то все проблемы опять сводятся к одной. Обновить инфу с сервера.
Проблема - сделать нормальную реакцию клиентской программы на отлуп сервера по нарушению правил целостности (которые должны быть). Любое обновление теряет актуальность сразу по получении оного. Т.е. снимается только часть (хоть и не малая) проблемы.

← →
clickmaker © (2006-11-24 10:05) [75]

> [71] MsGuns © (23.11.06 21:08)

не, ну в упор не понимаю, причем тут транзакция?
У нас есть набор неких объектов (места в зале, список товаров etc).
Мне нужно, что если один человек зарезервировал объект для потенциально длительной операции, другой, с другого рабочего места ДАЖЕ НЕ пытался бы его использовать. А как он может этого не делать, если он не видит текущего статуса объекта? Может попытаться, да, получить отлуп. Но почему бы не упредить его действия? Ведь это лишняя работа, а системы такие, как правило, работают в довольно жестком темпе.
Хорошо, термин "блокировка" я употребил неправильно, потому что он слишком пахнет спецификой СУБД. Ну пусть будет резервирование.
Ну хоть котлету из меня сделайте - не понимаю: каким боком тут транзакции, и в чем именно у меня "непонимание механизма обмена данными в технологии "клиент-сервер"?

← →
ANB © (2006-11-24 10:54) [76]

> Обновить инфу с сервера.

Сначала обновляешь вместе с блокировкой. И тогда, несмотря на мнение уважаемого Sergey13 © ты можешь быть уверен, что пока юзер чешет репу и пьет чай, глядя на форму редактирования, а потом одним пальцем с длинным ногтем печатаем там изменения - никто эту запись уже не заменит - она блокирована. А если клиентская программа навернется - блокировка снимется сама.

← →
Anatoly Podgoretsky © (2006-11-24 11:24) [77]

> clickmaker (24.11.2006 10:05:15) [75]

Как раз ты говоришь о блокировке, а не о резервировании. Никто другой не может редактировать и даже читать (термин использовать). А резервирование немного другое, например у на складе есть 10 единиц товара, количество товара не может переходить в минус.
Например первый оператор резервирует за собой 7 единиц, то другие могут получть только 3 и не более, по окончанию операции делается или проводка списания, или возрат резерва.
Оператор должен знать кто зарезервировал и когда.
Операция возврата штатная и может выполняться любым допущеным человеком, в отличии от блокировок она не мешает работе других пользователей, поскольку ничего ни физически, ни логически не блокируется.

← →
Anatoly Podgoretsky © (2006-11-24 11:26) [78]

> ANB (24.11.2006 10:54:16) [76]

А если клиентская программа навернется - блокировка снимется сама.

Ой ли, практика показывает, что это не так. Приходится администратору лезть на сервер и снимать блокировку.

← →
clickmaker © (2006-11-24 11:30) [79]

> [77] Anatoly Podgoretsky © (24.11.06 11:24)

так. Рассмотрим пример. Я кассир. продаю билеты на концерт. У меня на мониторе схема зала с местами. Свободные - белые, проданные черные. Другой кассир выделил, допустим, 3 места и оформляет заказ. Это может занять некоторое время. Это разве не резервирование с его стороны?

Вопрос: как мне узнать на этот период времени, что именно ЭТИ 3 места заняты, и мне даже не стоит щелкать по ним мышкой, чтобы отложить в другой заказ?

← →
Jeer © (2006-11-24 11:44) [80]

Все зависит от того, что считать под блокировкой.

Блокировка сервером кортежа во время транзакции совершенно нормальна, именно так и работают блокировочники.
Если сдохнет приложение, то блокировка автоматически снимется.

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

Короче говоря, надо уточнять какой уровень процессов обсуждается - уровень СУБД или уровень бизнес-процессов.

Пример.
Менеджер работает с клиентом (заказом клиента) и "ведет" его в течение м.б. нескольких дней, месяцев.
В этом случае должно выполняться резервирование (закрепление) клиента за конкретным менеджером. Это можно назвать блокировкой клиента для других менеджеров. Разумеется, здесь нет никакой транзакции в смысле СУБД, а может быть только откат (сторнирование) операции тем же менеджером или главным менеджером.

Как реально выполняется резервирование ?
У клиента X есть метка (поле IDM) - ID менеджера.
Например ID=0 - клиент ни за кем не закреплен и далее по номерам менеджеров.
Менеджер, обрадовавшись клиенту спешит закрепить его за собой.
Открывает форму с клиентами и ищет такового.
В зависимости от реализации процесса могут быть показаны все клиенты или только свободные клиенты.
Предположим реализация такова, что показаны все клиенты и не визуализированы признаки закрепленности.
Менеджер выбирает клиента X и нажимает кнопочку "Закрепить".
Приложение выполняет операцию с SQL командой:
UPDATE CLIENTS SET IDM = 1 WHERE ( ID = X ) AND ( IDM = 0 );

В данном случае, если клиент не занят, то происходит перезапись IDM с 0 на 1, если нет - то и не перезапишет.
По DBErrors приложение извещает менеджера о неудаче, т.е. о занятости клиента.

Прблема зависших блокировок клиента в данном случае может быть решена только административными и логическими методами.

← →
ANB © (2006-11-24 12:00) [81]

> Приходится администратору лезть на сервер и снимать блокировку.

Достаточно убить мертвую сессию.

> Вопрос: как мне узнать на этот период времени, что именно
> ЭТИ 3 места заняты, и мне даже не стоит щелкать по ним мышкой,
> чтобы отложить в другой заказ?

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

> clickmaker (24.11.2006 11:30:19) [79]

Резервирование и они должны быть отображены другим цветом, поскольку и них нет статуса Свободные/Проданые, но почему через блокировку это надо делать не пойму, надо сменить для данного конкретного случая (места в в зале) статус на Зарезервировано и все.
Узнать, тут просто пока не сделаешь запрос к серверу то не узнаешь, на экране показывается некоторое прошлое. Делают или кнопкой обновить, или имеют специальное окно для выбора со схемой распределения мест в зале, подойди к любой кассе и посмотри как это делают вручную. У кассира лежит бумажка со схемой мест в зале. Пока один кассир, то это не вызывает проблем, если больше одного, то это решают или распределением по диапазону или с помощью интеркома следующим образом - Резервирую место такое то, место такое то продано, место такое возвращено из резерва и все операторы отмечают это на бумажки.

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

> Время от времени рефрешить экран

это клиентское решение. Интересует, как на сервере это оформить. Сам же намекнул, что через доп. поле - это вчерашний век.
А как тогда? Статус-то места где хранить, если не в поле?

> [82] Anatoly Podgoretsky © (24.11.06 12:04)
> > clickmaker (24.11.2006 11:30:19) [79]
>
> Резервирование и они должны быть отображены другим цветом,
> поскольку и них нет статуса Свободные/Проданые, но почему
> через блокировку это надо делать не пойму, надо сменить
> для данного конкретного случая (места в в зале) статус на
> Зарезервировано и все

Господи, так а я об чем?
Ну неправильно я сказал "блокировка", но поправился уже ведь

> Сам же намекнул, что через доп. поле - это вчерашний век.
>
> А как тогда? Статус-то места где хранить, если не в поле?
>

Блокировка через поле - вчерашний век. А резервирование через него и делается. Нужно только в update обязательно вписать условие, проверяющее, что долей секунды раньше место не захапал другой оператор.
Короче - Jeer все объяснил.
Кистате, в элементарном случае с 3-мя статусами Свободно/Оформляется/Продано можно и на блокировках все замутить - только проблема с определением - ктож хапнул то ? Хотя конкретному кассиру обычно это и не нужно.

> ANB (24.11.2006 12:00:21) [81]

Продажа билетов, это то место где можно делать обновление схемы как по таймеру, так и по клику и сообщений не надо выдавать, просто перерисовать. Сообщение нужно когда удалось захватить (зарезервироваться). Можно и клиентку показывать на втором мониторе туже схему, как жест доброй воли к клиенту.

> clickmaker (24.11.2006 12:05:23) [83]

На сервере ничего не надо делать, на сервере всегда актуальное состояние.
Если сервер начинает что то рассылать, то он превращается в клиента. Это по определению клиент/сервер.

> clickmaker (24.11.2006 12:07:24) [84]

Так тебе постоянно и долдонят, что данный термин неправильный и ведет только к непониманию. При его использовании как минимум надо брать в кавычки, а лучше использовать более правильный термин.
Конечно русский язык гибкий, слишком гибкий.

> так и по клику и сообщений не надо выдавать, просто перерисовать

Не, с сообщением удобнее. Только его обязательно немодальным надо делать - что нибудь вроде статусной строки внизу формы. В случае проблем - выводить туда текст и делать красным. Если все ОК - выводить об этом текст и делать его черным. Не напрягает - не хочешь, не читай, и повышает информативность.

Ну хорошо, если все согласились, что дело только в терминологии, и данное решение имеет место быть, то я еще раз прошу уважаемого MsGuns объяснить мне
1) в чем мое непонимание технологии "клиент-сервер"
2) почему я должен обратить свое внимание именно на понятие "транзакции"
3) почему техника, которую я использую - "из песка и алебастра", и какие есть альтернативы. Именно для данной задачи

Обвинения нужно аргументировать

> clickmaker © (24.11.06 12:26) [90]

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

Транзакции совершенно необходимы в конкурирующих (параллельных) обращениях, когда логической единицей служат наборы операций (SELECT, INSERT, UPDATE,DELETE).

Скорее всего между вами произошло недопонимание терминов и кто-то погорячился.

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

так я вроде на протяжении всего разговора как раз об этом и говорю...

← →
Sl_RO (2006-11-24 13:09) [93]

clickmaker © (24.11.06 12:05) [83]
через доп. поле - это вчерашний век
Если поле в базе - то ДА.
Если "виртуальное" поле (вычислимое на сервере-приложений в 3х звенке)- то НЕТ: синглетон с блокировками (in mem) и клиенты с калк полем

> Если "виртуальное" поле (вычислимое на сервере-приложений
> в 3х звенке

вычислимое на основании чего?

> ANB (24.11.2006 12:14:25) [85]

set fld=value1 where fld<>value2

Гарантирует, что две одновременные транзакции не смогут привести в не консистентное состояние

> ANB (24.11.2006 12:23:29) [89]

Против статустной строки таких возражений нет, кроме дублирование, при щелчке сразу будет нужная информация прямо в месте щелчка. Цвет сменится и не только у данного места, а у всех измененых, а что бы не перегружать запрос, то можно использовать поля типа TimeStamp по терминологии МS SQL сервер, сейчас рекомендуют использовать синоним ROW_VERSION

> Jeer (24.11.2006 12:36:31) [91]

Транзакция все равно есть, только неявная, даже для SELECT
но явная нужна именно только пачки операций.

> Sl_RO (24.11.2006 13:09:33) [93]

Если трехзвенка то много вопросов решается, в том числе и состоянием.

> Anatoly Podgoretsky © (24.11.06 13:30) [97]

> Транзакция все равно есть, только неявная,

Это-то понятно, но мы пока не лезем в потроха движка СУБД.
Атомарной должна быть любая операция, в том числе и SELECT.
Надо будет - залезем:)

← →
SlymRO (2006-11-24 13:43) [100]

clickmaker © (24.11.06 13:11) [94]
вычислимое на основании чего?
На основании таблицы блокировок (ТБ) на сервере приложений (СП):
Клиент запрашивает данные у СП, СП к возвращаемым данным прицепляет доп. поле с вылукаплеными (о как сказал) значениями из ТБ. ТБ обязательно в памяти, но можно и на диск сбрасывать, но тогда при запуске сервера обязательно ее очищать.

> [100] SlymRO (24.11.06 13:43)
> clickmaker © (24.11.06 13:11) [94]
> вычислимое на основании чего?
> На основании таблицы блокировок (ТБ) на сервере приложений
> (СП):

мы говорим про клиент-сервер. У нас нету сервера приложений

> Jeer (24.11.2006 13:36:39) [99]

Атомарной, отдельная операция атомарно, поэтому явная транзакция не нужна.
Пакет не атомарен, поэтому явно.

> SlymRO (24.11.2006 13:43:40) [100]

Естественно сервер приложений может вести свои списки состояний.

> Jeer (24.11.2006 14:08:44) [104]

Дык основы :-)

>clickmaker © (24.11.06 12:26) [90]
>Ну хорошо, если все согласились, что дело только в терминологии, и данное решение имеет место быть, то я еще раз прошу уважаемого MsGuns объяснить мне

Дался Вам этот "Ганз" ;))

>1) в чем мое непонимание технологии "клиент-сервер"

потому что нет понимания "транзакций"

>2) почему я должен обратить свое внимание именно на понятие "транзакции"

Потому что это "сердце" любого сиквель-сервера

3) почему техника, которую я использую - "из песка и алебастра", и какие есть альтернативы. Именно для данной задачи

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

Обвинения нужно аргументировать

Я Вам приводил примеры, какие еще Вам нужны аргументы ? Или Вы думаете? что с точки зрения сиквель-сервера "Опербанк" и "Два кассира" есть? как говорят в Одессе? "две большие разницы" ?

ЗЫ. Еще раз повторяю, что если в моем "наезде" Вас больше всего покоробил акцент на значок, то я приношу извинения и забираю свои слова назад? этого будет достаточно для того, чтобы Вы перестали обмывать мои косточки ? ;)

> как реальных сущностей (полей БД) - а это уже по сути "локалка"
> со всеми вытекающими

Во - вы тоже за использование по возможности родных блокировок ?

>clickmaker © (24.11.06 17:55) [108]
>из какого моего поста это следует?

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

> [109] MsGuns © (25.11.06 23:12)

Ну хорошо. Вот мои первые посты

>Т.е. либо есть некий сервис, который оповещает остальных, что некто Вася >поменял запись 1. После 2 варианта. Либо переоткрытие датасета, либо >вообще не используется грид, а например ListView. Тогда можно >индивидуально управлять записями по ID.
>Еще вариант, если записей не слишком много, и жесткий риалтайм не >нужен, то по таймеру обновлять табличку на клиенте.

>Для особо критичных данных иногда применяют следующее. Грид >редактировать запрещают вообще. Только специальной формой. При >открытии формы запись блокируется. Все остальные после этого получают >либо отлуп, либо предложение открыть инфу для чтения. Эта идея с успехом >используется в офисных приложениях (ворд, эксель).
>Форма закрылась - блокировку снимаешь

Здесь я предлагал использовать технологию, которую Анатолий потом назвал "резервирование". Согласен, я неверно использовал термин, что видимо и вызвало у вас такую бурную реакцию.
Но не подумали же всерьез, что я предлагаю на открытие формы блокировать запись средствами сиквела или (что еще хуже) стартовать транзакцию, а при закрытии накатывать или откатывать?
Я может и не совсем заслуженно ношу значок, но я не настолько туп, знаете...

> clickmaker (26.11.2006 13:21:50) [110]

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

> ак настойчиво навязываемый Вами пример "двух кассиров",
> где будто бы надо чего-то разруливать и кого-то о чем-то
> оповещать, как раз и не нуждается ни в каких блокировках

Там где два, там может быть и двадцать два. Причем тут количество? Важен принцип. Я предлагал всего лишь использовать некое поле для обозначения статуса ОБЪЕКТА, именно объекта, а не записи. Зарезервирован, свободен, продан и т.д. - набор состояний зависит от предметной области. Я сам противник использования напропалую каких-либо специфичных для серверов БД фич, о чем, кстати, здесь упоминал.
Вы же налетели как коршун, даже не попытавшись разобраться, о чем речь. Вот что обидно, а не "честь мундира"....

> clickmaker (26.11.2006 18:13:52) [112]

А ты чего то другого ожидал от публичного форума?

> [113] Anatoly Podgoretsky © (26.11.06 18:28)
> > clickmaker (26.11.2006 18:13:52) [112]
>
> А ты чего то другого ожидал от публичного форума?

Я начинаю понимать, почему америкосы обходят нас по части ПО. Английский язык допускает гораздо меньше неоднозначностей в терминах, и они быстрее договариваются... ))

> [112] clickmaker ©

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

> [103] Anatoly Podgoretsky ©

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

> clickmaker (26.11.2006 18:36:54) [114]

Конечно, один перевод термина потоки чего стоит.

Совместное использование одной таблицы Найти похожие ветки