Есть БД, в ней табличка, которая с помошью OR-мапера (своего) отображается в виде списка обьектов бизнес-класа. И если открыть на редактирование некую запись двумя пользователями, то при сохранении прав будет тот — кто последний. Собстевнно вопрос простой: как не дать редактировать бизнес обьект двум пользователям одновременно.
Мысль пока такая: сделать табличку блокировки, где собственно при начале редактирования делать запись что данный обьект такого-то класа с таким-то ИД редактируется. И при попытке снова редактировать — делать проверку на наличие таковой записи.. Делитесь идеями.
-----------------------------------------
тут может быть ваша реклама
S>Курить пессимистическую блокировку. А луше, заодно и оптимистическую.
Ну, знаете.. Это обобщение. Допустим я в теории решил для себя что нужна пессимистическая (что я и предложил как свой пример). Вопрос был собственно в идеях реализации, а не в том как это обобщенно назвать
-----------------------------------------
тут может быть ваша реклама
Здравствуйте, nauro, Вы писали:
S>>Курить пессимистическую блокировку. А луше, заодно и оптимистическую. N>Ну, знаете.. Это обобщение. Допустим я в теории решил для себя что нужна пессимистическая (что я и предложил как свой пример). Вопрос был собственно в идеях реализации, а не в том как это обобщенно назвать
Обычно механизм прост — в таблицу добавляется колонка, куда пишутся флаги или время начала блокировки (со временем есть определенные сложности, связанные с синхронизацией часов).
Что именно привело к мысли создания специальной таблицы? Универсальность блокировки разных таблиц?
Здравствуйте, nauro, Вы писали:
S>>Курить пессимистическую блокировку. А луше, заодно и оптимистическую. N>Ну, знаете.. Это обобщение. Допустим я в теории решил для себя что нужна пессимистическая (что я и предложил как свой пример). Вопрос был собственно в идеях реализации, а не в том как это обобщенно назвать
Реализация зависит от используемой CУБД. Ну, и, глобально, от топологии предметной области.
Поясняю на пальцах: крайне нежелательна возможность дедлоков в проектируемой системе. Стало быть, надо позаботиться об упорядочении накладываемых блокировок.
В разных случаях это достигается разными средствами. В частности, если речь идет о плоском списке независимых объектов, то можно выдавать по локу на каждый объект и не париться. Если предметная область имеет иерархическую структуру, то возникает необходимость в серии различных локов таким образом, чтобы, к примеру, пользователь А не отпилил ветку дерева, в которой сейчас редактирует пользователь B.
S>Что именно привело к мысли создания специальной таблицы? Универсальность блокировки разных таблиц?
Именно, хотелось бы создать механизм, а кто его будет использовать (в смысле какой бизнес-класс) пофигу.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
-----------------------------------------
тут может быть ваша реклама
И все таки, допустим на время, что нету у меня древовидной структуры данных. Как бы вы тогда реализовывали пессимистический вариант НЕ затрагивая структуру таблиц, где нужно реализовать блокировку редактирования?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
-----------------------------------------
тут может быть ваша реклама
Здравствуйте, nauro, Вы писали: N>И все таки, допустим на время, что нету у меня древовидной структуры данных. Как бы вы тогда реализовывали пессимистический вариант НЕ затрагивая структуру таблиц, где нужно реализовать блокировку редактирования?
Может быть, имеет смысл кликнуть по ссылке и почитать обсуждение?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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> Я бы хотел создать отдельную програму/сервис, которая будет управлять блокировками обьектов всех клиентов.
Не прокатит. У тебя единственный путь — блокировки хранить на сервере БД, переделать клиентов так, чтобы они правильно работали с блокировками. Не забыть заменить всех клиентов!
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Сообщение заговорено потомственным колдуном, целителем и магом в девятом поколении!
Модерирование или минусование сообщения ведет к половому бессилию, венерическим заболеваниям, венцу безбрачия и диарее!