Есть БД, в ней табличка, которая с помошью OR-мапера (своего) отображается в виде списка обьектов бизнес-класа. И если открыть на редактирование некую запись двумя пользователями, то при сохранении прав будет тот — кто последний. Собстевнно вопрос простой: как не дать редактировать бизнес обьект двум пользователям одновременно.
Мысль пока такая: сделать табличку блокировки, где собственно при начале редактирования делать запись что данный обьект такого-то класа с таким-то ИД редактируется. И при попытке снова редактировать — делать проверку на наличие таковой записи.. Делитесь идеями.

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

N>Делитесь идеями.
Курить пессимистическую блокировку. А луше, заодно и оптимистическую.

S>Курить пессимистическую блокировку. А луше, заодно и оптимистическую.
Ну, знаете.. Это обобщение. Допустим я в теории решил для себя что нужна пессимистическая (что я и предложил как свой пример). Вопрос был собственно в идеях реализации, а не в том как это обобщенно назвать

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

S>>Курить пессимистическую блокировку. А луше, заодно и оптимистическую.
N>Ну, знаете.. Это обобщение. Допустим я в теории решил для себя что нужна пессимистическая (что я и предложил как свой пример). Вопрос был собственно в идеях реализации, а не в том как это обобщенно назвать

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

Что именно привело к мысли создания специальной таблицы? Универсальность блокировки разных таблиц?

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

S>>Курить пессимистическую блокировку. А луше, заодно и оптимистическую.
N>Ну, знаете.. Это обобщение. Допустим я в теории решил для себя что нужна пессимистическая (что я и предложил как свой пример). Вопрос был собственно в идеях реализации, а не в том как это обобщенно назвать
Реализация зависит от используемой CУБД. Ну, и, глобально, от топологии предметной области.

Поясняю на пальцах: крайне нежелательна возможность дедлоков в проектируемой системе. Стало быть, надо позаботиться об упорядочении накладываемых блокировок.
В разных случаях это достигается разными средствами. В частности, если речь идет о плоском списке независимых объектов, то можно выдавать по локу на каждый объект и не париться. Если предметная область имеет иерархическую структуру, то возникает необходимость в серии различных локов таким образом, чтобы, к примеру, пользователь А не отпилил ветку дерева, в которой сейчас редактирует пользователь B.

После того, как вопрос с архитектурой локов решен положительно, можно заняться реализацией. Что-то подобное уже обсуждалось: http://rfd.rsdn.ru/forum/message/91161.aspx

S>Что именно привело к мысли создания специальной таблицы? Универсальность блокировки разных таблиц?
Именно, хотелось бы создать механизм, а кто его будет использовать (в смысле какой бизнес-класс) пофигу.

S>После того, как вопрос с архитектурой локов решен положительно, можно заняться реализацией. Что-то подобное уже обсуждалось: http://rfd.rsdn.ru/forum/message/91161.aspx

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

Здравствуйте, nauro, Вы писали:
N>И все таки, допустим на время, что нету у меня древовидной структуры данных. Как бы вы тогда реализовывали пессимистический вариант НЕ затрагивая структуру таблиц, где нужно реализовать блокировку редактирования?
Может быть, имеет смысл кликнуть по ссылке и почитать обсуждение?

Здравствуйте, Sinclair, Вы писали:
S>Может быть, имеет смысл кликнуть по ссылке и почитать обсуждение?

Хочется еще раз поднять тему. (наверно очень долго я читал ТО обсуждение ). Есть проблема с БД. Точнее ее нет, но вариант с использованием локов в самой СУБД я бы хотел откинуть (если можно не спрашивайте почему, ибо не от меня зависит). Так вот. Раз вариант с локами в СУБД откидывается, хочется найти другой путь. Первое что приходит в голову — это TCPIP Client/Server. Т.е. есть сервер который обрабатывает запросы со всех клиентов где то в таком виде:
1. клиент А блокирует обьект Х1 на редактирование
2. сервер смотрит не заблокирован ли обьект Х1 — нет — дает добро (и помечает у себя блокировку)
3. клиент Б блокирует обьект Х2
4. сервер НЕ дает добро, клиент сообщает пользователю о невозможности редактирования данного обьекта

Второй вариант что напрашивается Remoting.

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

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

N>Здравствуйте, Sinclair, Вы писали:
S>>Может быть, имеет смысл кликнуть по ссылке и почитать обсуждение?

N>Хочется еще раз поднять тему. (наверно очень долго я читал ТО обсуждение ). Есть проблема с БД. Точнее ее нет, но вариант с использованием локов в самой СУБД я бы хотел откинуть (если можно не спрашивайте почему, ибо не от меня зависит). Так вот. Раз вариант с локами в СУБД откидывается, хочется найти другой путь. Первое что приходит в голову — это TCPIP Client/Server. Т.е. есть сервер который обрабатывает запросы со всех клиентов где то в таком виде:
N>1. клиент А блокирует обьект Х1 на редактирование
N>2. сервер смотрит не заблокирован ли обьект Х1 — нет — дает добро (и помечает у себя блокировку)
N>3. клиент Б блокирует обьект Х2
N>4. сервер НЕ дает добро, клиент сообщает пользователю о невозможности редактирования данного обьекта

Есть две возможности: не давать пользователю редактировать объект изначально если кто-то его редактирует (отображать ридонли или вообще не отображать); либо дать таки пользователю редактировать данные и сообщать об ошибке (в случае если кто-то редактирует) в момент когда данные заливаются на сервер. Какой подход выбираешь? Я бы вынес сие в конфиг...

N>Второй вариант что напрашивается Remoting.
А что за вариант?

N>Что посоветуете?
Честно говоря (ты не обижайся если что... я тебе умный вещь скажу только ты не обижайся ) я бы в данной ситуации перечитал бы главы ряда книг по БД. Главы про транзакции и блокировки... Это как я бы действовал в такой ситуации первым делом...

Здравствуйте, Ellin, Вы писали:
E>Есть две возможности: не давать пользователю редактировать объект изначально если кто-то его редактирует (отображать ридонли или вообще не отображать); либо дать таки пользователю редактировать данные и сообщать об ошибке (в случае если кто-то редактирует) в момент когда данные заливаются на сервер. Какой подход выбираешь? Я бы вынес сие в конфиг...
подход №1. ака пессимистическая блокировка.

E>Честно говоря (ты не обижайся если что... я тебе умный вещь скажу только ты не обижайся ) я бы в данной ситуации перечитал бы главы ряда книг по БД. Главы про транзакции и блокировки... Это как я бы действовал в такой ситуации первым делом...

Да за что обижатся-то? Хороший совет — никогда не в обиду, но в том то и дело, что вариант с использованием БД для блокировок отпадает однозначно (я это сказал в начале моего предыдущего поста).

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

N>Здравствуйте, Ellin, Вы писали:
E>>Есть две возможности: не давать пользователю редактировать объект изначально если кто-то его редактирует (отображать ридонли или вообще не отображать); либо дать таки пользователю редактировать данные и сообщать об ошибке (в случае если кто-то редактирует) в момент когда данные заливаются на сервер. Какой подход выбираешь? Я бы вынес сие в конфиг...
N>подход №1. ака пессимистическая блокировка.

E>>Честно говоря (ты не обижайся если что... я тебе умный вещь скажу только ты не обижайся ) я бы в данной ситуации перечитал бы главы ряда книг по БД. Главы про транзакции и блокировки... Это как я бы действовал в такой ситуации первым делом...

N>Да за что обижатся-то? Хороший совет — никогда не в обиду, но в том то и дело, что вариант с использованием БД для блокировок отпадает однозначно (я это сказал в начале моего предыдущего поста).
Так я предлагаю реализовывать аки в БД... Писать свою БД лайт

А что с ремойтингом хочешь делать я не понял...

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

E>Так я предлагаю реализовывать аки в БД... Писать свою БД лайт
Мда. Чет велик изобретать не хочется.
E>А что с ремойтингом хочешь делать я не понял...
Дык тоже что и с tcpip client/server. просто средствами .net remoting

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

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

E>>Так я предлагаю реализовывать аки в БД... Писать свою БД лайт
N>Мда. Чет велик изобретать не хочется.
Тогда на COM+ пиши — там транзакции есть. А еще лучше на WCF — я его еще не знаю, но вроде бы там есть то что тебе нужно. ИМХО WCF гораздо предпочтительнее.

N>Дык тоже что и с tcpip client/server. просто средствами .net remoting
Ну а какая разница, какой у тебя транспортный уровень в данном случае... ремоутинг транзакции не поддерживает.

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

N>Здравствуйте, Sinclair, Вы писали:
S>>Может быть, имеет смысл кликнуть по ссылке и почитать обсуждение?

...

N>Что посоветуете?
Сервер блокировок — вполне рабочий вариант. В SAP такой подход используется.

Здравствуйте, Кондраций, Вы писали:

К>Сервер блокировок — вполне рабочий вариант. В SAP такой подход используется.
Вот отсюда, пожалуйста, поподробней. Что за сервер блокировок и как его использовать.

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

N>Здравствуйте, Кондраций, Вы писали:

К>>Сервер блокировок — вполне рабочий вариант. В SAP такой подход используется.
N>Вот отсюда, пожалуйста, поподробней. Что за сервер блокировок и как его использовать.
Пожалуй в данном случае узнать сколько стоит и как достать.

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

N>Здравствуйте, Кондраций, Вы писали:

К>>Сервер блокировок — вполне рабочий вариант. В SAP такой подход используется.
N>Вот отсюда, пожалуйста, поподробней. Что за сервер блокировок и как его использовать.
Да ничего особенного. Просто надо представлять организацию сервера SAP по процессам операционной системы. Вкратце: есть несколько рабочих процессов, обрабатывающих запросы клиента. Чтобы обеспечить пессимистическую блокировку, организовали ещё один процесс, в котором хранится информация о блокировании бизнес-объектов (это и есть сервер блокировок). В программе ты должен считать бизнесобъект, запросить блокировку, сделать, что нужно, освободить блокировку.
Собственно, это то, что ты и описал. Если у тебя только один серверный процесс, то выделять сервер блокировок в отдельный процесс смысла нет.

Здравствуйте, Кондраций, Вы писали:
К>Собственно, это то, что ты и описал. Если у тебя только один серверный процесс, то выделять сервер блокировок в отдельный процесс смысла нет.
Есть сервера БД основные, и удаленные (о них не говорим это отдельная тема). Есть много клиентов, которые посредством десктопного приложения управляют данными в БД. Я бы хотел создать отдельную програму/сервис, которая будет управлять блокировками обьектов всех клиентов.

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

N>Здравствуйте, Кондраций, Вы писали:
К>>Собственно, это то, что ты и описал. Если у тебя только один серверный процесс, то выделять сервер блокировок в отдельный процесс смысла нет.
N>Есть сервера БД основные, и удаленные (о них не говорим это отдельная тема)
Сервера БД либо приложений?

N>. Есть много клиентов, которые посредством десктопного приложения управляют данными в БД.
Судя по всему — двухуровневое клиент-серверное приложение: толстый клиент + какой-нить типа MSSQL.

N> Я бы хотел создать отдельную програму/сервис, которая будет управлять блокировками обьектов всех клиентов.
Не прокатит. У тебя единственный путь — блокировки хранить на сервере БД, переделать клиентов так, чтобы они правильно работали с блокировками. Не забыть заменить всех клиентов!