Гость
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Одновременное изменение документа / 25 сообщений из 61, страница 1 из 3
20.05.2007, 19:15
    #34538298
Eugene7
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
Есть БД, и 5-10 клиентов к нему подключенных.
Как лучше сделать синхронизацию изменений одного и того же документа, если он редактируеться с двух разных клиентов в одно и то же время?
Редактирование пакетное - при открытии запрашиваеться вся инфа по доку, закидываеться в контролы/кэшируеться. При нажатии на "сохранить" пишет в базу.
Я вижу три пути:
1. Если кем то документ открыт на редактирование, другие могут открыть лишь на просмотр. То бишь при открытии проверять, открыт ли кем то еще, и если так, то дизаблить контролы.
2. При сохранении менять лишь то, что было изменено. Но тут надо будет проверять, что же изменилось. Данных много. Придеться проходить проходить по всем данным и сверять, что тоже не очень нравиться. Либо сделать систему, которая регистрирует изменения. Но насмотревшись на это всяких вордах(где внес изменение, потом исправил обратно, а при закрытии он все равно считает что ты что-то изменил) тоже не в восторге.
3. Если какой то параметр был изменен, обновлять его на других клиентах прямо в открытой форме. Тоже не очень нравиться решение(много сложностей с узнавание что что-то изменилось и обновлением этого).
...
Рейтинг: 0 / 0
20.05.2007, 19:17
    #34538301
Eugene7
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
Собственно хочеться услышать ваши мнения, и как это сделано на других системах
...
Рейтинг: 0 / 0
20.05.2007, 20:11
    #34538349
UrryMcA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
http://shara.by/download/~file=421c6b9bca81d3e7d7ce845f23381c05244799b7
или http://www.mirknig.com/2006/09/27/martin_fauler_arkhitektura_korporativnykh_programmnykh_prilozhenijj_ispravlennoe_izdanie.html
...
Рейтинг: 0 / 0
21.05.2007, 00:04
    #34538514
Александр Гoлдун
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
Eugene7
Я вижу три пути:
1. Если кем то документ открыт на редактирование, другие могут открыть лишь на просмотр. То бишь при открытии проверять, открыт ли кем то еще, и если так, то дизаблить контролы.
2. При сохранении менять лишь то, что было изменено. Но тут надо будет проверять, что же изменилось. Данных много. Придеться проходить проходить по всем данным и сверять, что тоже не очень нравиться. Либо сделать систему, которая регистрирует изменения. Но насмотревшись на это всяких вордах(где внес изменение, потом исправил обратно, а при закрытии он все равно считает что ты что-то изменил) тоже не в восторге.
3. Если какой то параметр был изменен, обновлять его на других клиентах прямо в открытой форме. Тоже не очень нравиться решение(много сложностей с узнавание что что-то изменилось и обновлением этого).
Пункт 2 желателен, и он никак не противоречит первому. Однозначно при открытии одним на редактирование другим давать только просмотр. Блокировка прикладного уровня реализуется элементарнейше независимо от типа сервера БД: одна таблица блокировок и две процедуры: заблокировать объект и снять блокировку.
Пункт 3 в общем случае может оказаться неприемлемым бредом: принципиальных технических проблем в реализации подобного нет, но логических казусов может быть немеряно. Например один правит валюту документа, другой цену, один правит кол-во, другой ассотимент и т.д. Просмотр документа должен быть статическим. А то открыл документ, отвернулся - а за этот миг там поменялись отображаемые данные. Разумеется, если пока я смотрел документ, а другой в это время внес в него изменения и сохранил их, то если я захочу начать редактировать открытый на просмотр документ, система должна отследить, что были изменения, из-за которых отображенное у меня в форме уже неактуально и как-то отреагировать на это.
...
Рейтинг: 0 / 0
21.05.2007, 09:28
    #34538761
Xoxerix
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
посмотрите как сделано в гугл догз.
...
Рейтинг: 0 / 0
21.05.2007, 10:19
    #34538871
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
Eugene7 пишет:
> Есть БД, и 5-10 клиентов к нему подключенных.
> Как лучше сделать синхронизацию изменений одного и того же документа,
> если он редактируеться с двух разных клиентов в одно и то же время?

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

> Редактирование пакетное - при открытии запрашиваеться вся инфа по доку,
> закидываеться в контролы/кэшируеться. При нажатии на "сохранить" пишет в
> базу.

А вот это плохо. Если бы было непакетное, можно было бы просто
оставить все на мелких атомарных консистентных транзакциях.

Первое решение самое мудрое. и по-моему правильное.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
21.05.2007, 11:38
    #34539079
Александр Гoлдун
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
MasterZiv
Eugene7 пишет:
> Есть БД, и 5-10 клиентов к нему подключенных.
> Как лучше сделать синхронизацию изменений одного и того же документа,
> если он редактируеться с двух разных клиентов в одно и то же время?

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

Только если они расположены в одном кабинете. В других же случаях, как показывает практика, конфликты могут происходить весьма часто.

MasterZiv
> Редактирование пакетное - при открытии запрашиваеться вся инфа по доку,
> закидываеться в контролы/кэшируеться. При нажатии на "сохранить" пишет в
> базу.

А вот это плохо. Если бы было непакетное, можно было бы просто
оставить все на мелких атомарных консистентных транзакциях.

Почему плохо? Я бы сказал наоборот: это единственный правильный вариант. Или по крайней мере один из лучших.
Пример сценария: открываю документ на редактирования, вношу разные изменения в разные его части. А потом по каким-либо причинам передумываю. В варианте пакетного изменения документа достаточно нажать кнопку "Отменить" или что-то типа того документ останется в исходном виде, как до начала редактирования. Как это сделать без пакетного изменения документа? Делать все в долгоиграющей транзакции? Ну-ну
И потом, атомарные консистентные транзакции по изменению каждого атрибута могут привести к неконсистентности документа в целом на прикладном уровне
...
Рейтинг: 0 / 0
21.05.2007, 13:06
    #34539362
gardenman
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
Один документ состоит из нескольких строк с нескольких таблицах. Обычно поступают просто (на блокировочниках естесс-но). Перед тем как сохранять документ обновляют (или пытаются обновить) время модификации документа. Вариантов несколько - либо документ кем-то заблокирован, либо его кто-то уже изменил. Ну а дальше - уже и так понятно.
...
Рейтинг: 0 / 0
21.05.2007, 13:33
    #34539451
Александр Гoлдун
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
gardenmanОдин документ состоит из нескольких строк с нескольких таблицах. Обычно поступают просто (на блокировочниках естесс-но). Перед тем как сохранять документ обновляют (или пытаются обновить) время модификации документа. Вариантов несколько - либо документ кем-то заблокирован, либо его кто-то уже изменил. Ну а дальше - уже и так понятно.
IMHO кривой вариант. Почему проверка делается перед сохранением документа а не перед началом редактирования? Это приведет к тому, что документ смогут начать редактировать одновременно несколько человек. Если процесс редактирования документа будет долгим, то можно при такой реализации получить кучу нецензурной брани в свой адрес.

Ну простейшая же логика! зачем велосипеды придумывать?
1. Просматривать документ может любое количество человек одновременно
2. Открытая на просмотр форма документа не делает самопроизвольное изменение отображения. Просмотр статичен, что бы там ни делали другие с этим документом.
3. Перед началом редактирования документа форма делает следующее:
а) проверяет, не поменялся ли документ с момента открытия на просмотр. Если поменялся, то пользователь об этом предупреждается и форма загружает свежую версию на просмотр.
б) Пытается получить блокировку документа для редактирования. Если не получается - ругается, сообщая почему (кто и с какого момента сейчас правит этот документ)
4. При отмене редактирования форма просто убирает свою блокировку
5. При сохранении после успешного завершения форма просто убирает свою блокировку

Блокировку прикладного уровня нет смысла завязывать на серверные блокировки. Делается элементарная таблица блокировок: что именно, кем, когда заблокированно.
Делается процедура типа LockObject(тип объекта, код объекта), которая делает поиск соответствующей записи в блокировках. Если не находит, то создает новую. Если находит, то ругается, сообщая кем заблокировано.
Соответственно делается еще процедура UnLockObject

Плюс нужен механизм отработки аварийного завершения клиента для очистки зависших блокировок.
...
Рейтинг: 0 / 0
21.05.2007, 13:53
    #34539538
Alexey Kudinov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
Александр ГoлдунНу простейшая же логика! зачем велосипеды придумывать?
IMO вы описали [действительно распространенный и в общем неплохой] способ решить проблему, которая лежит не в области IT поддержки. Почему в один момент времени разные пользователи могут редактировать один документ ? Пускай бизнес хорошо подумает над этим казалось бы детским вопросом, а подумав выбирает из двух вариантов:

1 либо "кто последний - тот и прав".
2 либо храним историю изменения документа.

На эти 2 варанта еще накладываются различные статусы документа.
...
Рейтинг: 0 / 0
21.05.2007, 14:37
    #34539713
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
> Я вижу три пути:

Как это обычно бывает, правильный путь - четвертый. ;)

Если конкурирующие версии документов - редкая ситуация, есть смысл реализовать первый из перечисленных вариантов. Если конкурирующие версии документов - обычная практика, есть смысл подумать над более общим решением, позволяющим не терять изменения, сделанные любым пользователем. Посмотрите, например, как работает Subversion.
...
Рейтинг: 0 / 0
21.05.2007, 15:37
    #34539933
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
Александр Гoлдун пишет:

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

Я не люблю блокирование вообще. Я думаю что оно не нужно в 90% случаев.
А так надо вообще блокировать документ эксклюзивно по хорошему,
даже на чтение.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
21.05.2007, 16:52
    #34540208
mcureenab
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
Распространённые варианты.

1. Блокировка записи перед её изменением. Если запись уже изменена другим пользователем, система предлагает сделать повторный запрос, чтобы локальный буфер соответствовал сосотоянию БД, или отказаться от затеи. Если запись заблокирована другим пользователем, пользователь получает сообщение и может повторить попытку заблокировать запись, или отказаться от затеи.

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

2. Неблокирующее изменение записи. Запись изменяется в локальном буфере без блокировки, а затем сохраняется с проверкой на предмет изменения конкурирующим пользователем. Могут проверяться только ключевые поля (PK), PK и изменённые поля или все поля записи. Тут пользователь может проигнорировать чужие изменения, может отказаться от затеи. Если запись с данным PK не найдена, то считается что она удалена и изменить её нельзя.

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

3. Продвинутые системы управления версиями документов позволяют параллельно редактировать документы (их части), а затем сливать изменения. В простых случаях слияние может происходить автоматически. В случае конфликта, слияние делает пользователь системы.

Если документы большие и требуют много времения на редактирование создать и удерживать системную блокировку практически невозможно. Как правило, пользователь с помощью разделяемой прикладной блокировки получает предупреждение, что ктото уже забрал документ на редактирование.
...
Рейтинг: 0 / 0
21.05.2007, 16:54
    #34540213
Urri
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
Ну что можно сказать по этому поводу: как весь мир делится на оптимистов и пессимистов, так и наше приложение может относиться к одной из этих сторон.

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

Пессимистически настроенное приложение предполагает, что вероятность совместного редактирования велика, поэтому оно ставит блокировку сразу же, как только наш пользователь начнет редактирование, и снимает ее только после того, как изменения будут сохранены. Это гарантирует от набивания данных впустую, но зато в таких приложениях бывают проблемы длинных перекуров. Когда один пользователь начал работу с документом утром, потом его отвлекли, и далее до вечера он не вспоминал о том, что что-то по его вине заблокировано, а все прочие пользователи, которые тоже хотели внести изменения в те же записи, сильно ругались.
Приложение, написанное подобным образом, должно либо предоставлять возможность администратору снять долгую блокировку, либо делать это автоматически, например, по превышении периода ожидания реакции пользователя.
________
Не дадим распространиться заразе политкорректности!
...
Рейтинг: 0 / 0
21.05.2007, 17:28
    #34540293
Александр Гoлдун
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
guest_20040621
Если конкурирующие версии документов - редкая ситуация, есть смысл реализовать первый из перечисленных вариантов. Если конкурирующие версии документов - обычная практика, есть смысл подумать над более общим решением, позволяющим не терять изменения, сделанные любым пользователем. Посмотрите, например, как работает Subversion.
Красиво звучит, но плохо представляю себе на практике. Вернемся с небес на землю, возьмем для примера банальнейший документ - накладную. Что такое конкурирующие версии накладной? Или может есть какие-то более удачные примеры?
...
Рейтинг: 0 / 0
21.05.2007, 17:35
    #34540311
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
Александр Гoлдун пишет:

> такое конкурирующие версии накладной? Или может есть какие-то более
> удачные примеры?

Вот и я говорю, что все равно всегда административными методами разруливается.
т.е. абсолютно согласен с предыдущим оратарам. Небывает конкурирующих версий
накладных. Есть ответственный чел, который ее делает. Если он уже ее не делает,
то это его начальник. И т.п.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
21.05.2007, 18:04
    #34540379
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
> плохо представляю себе на практике

Прайс-лист себе хорошо представляете? Представляете, как один сотрудник меняет розничные цены, второй - оптовые, третий - крупнооптовые? Договор представляете? Можете представить, что юрист пишет раздел "ответственность сторон", а менеджер вносит изменения в "условия поставки"?
...
Рейтинг: 0 / 0
21.05.2007, 18:09
    #34540399
mcureenab
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
MasterZiv
Александр Гoлдун пишет:

> такое конкурирующие версии накладной? Или может есть какие-то более
> удачные примеры?

Вот и я говорю, что все равно всегда административными методами разруливается.
т.е. абсолютно согласен с предыдущим оратарам. Небывает конкурирующих версий
накладных. Есть ответственный чел, который ее делает. Если он уже ее не делает,
то это его начальник. И т.п.
Posted via ActualForum NNTP Server 1.4

Для документов я не вижу смысла в многоверсионности. Однако для разработки ПО, в этом может быть смысл. Например можно иметь и развивать несколько версий исходника. Оракл сейчас поддерживат версии 9i, 10g и разрабатывает 11g, таким образом могут быть актуальными минимум 3 версии исходников.
...
Рейтинг: 0 / 0
21.05.2007, 18:10
    #34540408
mcureenab
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
guest_20040621> плохо представляю себе на практике

Прайс-лист себе хорошо представляете? Представляете, как один сотрудник меняет розничные цены, второй - оптовые, третий - крупнооптовые? Договор представляете? Можете представить, что юрист пишет раздел "ответственность сторон", а менеджер вносит изменения в "условия поставки"?

А при чём тут разные версии? Это не версии, а части документа которые потом объединяются простой конкатенацией.
...
Рейтинг: 0 / 0
21.05.2007, 18:12
    #34540415
Сахават Юсифов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
guest_20040621> плохо представляю себе на практике

Прайс-лист себе хорошо представляете? Представляете, как один сотрудник меняет розничные цены, второй - оптовые, третий - крупнооптовые? Договор представляете? Можете представить, что юрист пишет раздел "ответственность сторон", а менеджер вносит изменения в "условия поставки"?

Тут уже все разделено организационно.
...
Рейтинг: 0 / 0
21.05.2007, 18:31
    #34540496
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
> Тут уже все разделено организационно.

Это пример простых документов, для которых коллективная работа имеет смысл. По поводу "все разделено организационно" - представьте, что изменения, скажем, в розничный прайс-лист вносятся не одним сотрудником, а несколькими. Причем, территориально рабочие места разнесены.
...
Рейтинг: 0 / 0
21.05.2007, 18:44
    #34540532
Сахават Юсифов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
guest_20040621> Тут уже все разделено организационно.

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

Вот хорошо было б если документ сам управлял собой. :)
...
Рейтинг: 0 / 0
21.05.2007, 19:00
    #34540574
mcureenab
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
Сахават ЮсифовВот хорошо было б если документ сам управлял собой. :)

Документ по сути своей объект пассивный. Для управления документом служат менеджеры транзакций, системы контроля версий и т.д. Какие в них правила заложены, так они документом и управляют.
...
Рейтинг: 0 / 0
21.05.2007, 19:12
    #34540611
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
> документы такого типа - композитные по сути своей

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

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

> Вот хорошо было б если документ сам управлял собой

В смысле "сам управлял собой"?
...
Рейтинг: 0 / 0
21.05.2007, 19:19
    #34540628
Сахават Юсифов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Одновременное изменение документа
Меня лично напрягают все эти СУБД.
По мне бы - разделить ведение документа от его анализа.
Каждый документ имел бы какие-то теги (авторы, допущенные, к каким частям, на какие действия и т.д.). Менеджер этого дока управлял бы доступностью (кто запрсил, с какими намерениями менял бы видимость или статус для изменений и т.д.), и параллельно выводил бы в отделнюю БД части для анализа на которые есть подписка и управлял бы синхронизацией этих частей.
Так сумбурно.
...
Рейтинг: 0 / 0
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Одновременное изменение документа / 25 сообщений из 61, страница 1 из 3
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]