Добрый день всем! Не могу выбрать вариант блокировки документов в СЭД, например: для фоновый задач (агентов) или для исключения одновременного редактирования документа (набора документов) двумя пользователями. Document Locking не очень нравится. Есть ли у вас какие нибудь оптимальные решения этого вопроса?
-
3 марта 19:00 бесплатный вебинар с куратором курса
Пентест инфраструктуры Active Directory
>>> Подробнее <<<
вот не знаю кто что предложит. Но, боюсь, единственный способ, это отдать пользвоателю копию документа, потом, на "центральном" сервере, агентом, проверяются пользовательские изменения, и делаются соотвествующие изменения в нормальном документе. Насколько я понимаю, некоторые СЭД так и работают. Яже, в определённый момент, к сожалению, прохлопал это, а сейчас, что-то менять, это переколбашивать ядро по полной...
Оптимальных нет, есть куча идей, по крайней мере моя (еще не реализовывал):
1. База для локов, реплика на все сервера. Скорость реплики 1-2 секунды (ну да в идеале, кластер хорошее решение)
2. При открытии проверять наличие документа-лока, ключ поиска UNID открываемого дока.
3. Если есть - сообщение или открытие только на чтение, если нет - создать.
4. При закрытии документ либо удалять, либо метить к удалению, чтобы его другой пользователь не нашел.
Все фоновые задачи по изменению документов должны идти или ночью, или в минимально загруженное время.
Выполнятся только на одном из серверов реплики.
Перед обработкой документа проверить открыт ли он кем-либо через базу локов.
При save использовать лучше связку, на всякий случай:
Не знаю, конечно, сильно ли это снизит конфликты, но возможно...
1. База для локов, реплика на все сервера. Скорость реплики 1-2 секунды (ну да в идеале, кластер хорошее решение)
2. При открытии проверять наличие документа-лока, ключ поиска UNID открываемого дока.
3. Если есть - сообщение или открытие только на чтение, если нет - создать.
4. При закрытии документ либо удалять, либо метить к удалению, чтобы его другой пользователь не нашел.
Все фоновые задачи по изменению документов должны идти или ночью, или в минимально загруженное время.
Выполнятся только на одном из серверов реплики.
Перед обработкой документа проверить открыт ли он кем-либо через базу локов.
При save использовать лучше связку, на всякий случай:
Код:
if doc.Save(false, doc.isresponse) then
priint "save"
end ifДа, тоже вариант, можно еще версионность прикрутить.
Обработку изменений можно через очередь запросов.
Вот только остается вопрос времени и скорости обработки...
И для агентов это не подходит, но для пользователей вполне возможно.
Добавлено: Serduko
А без центрального сервера не получится... Опять же почему дорогой?
Сервера уже есть, что мешает один из них приспособить для этого.
Другое дело настроить реплики, это может оказаться не так просто.
Дело не только в сервере и в репликах, да в общем и не в ресурсоемкости тоже. Сама логика меня смущает, как потом эти копии схлопывать на центральном сервере, может быть такая ситуация, когда данные будут противоречить друг другу? А если не схлопывать, то какой смысл вообще, тратить ресурс на сравнивание полей?
а это также как программная обработка репл.конфликтов. Сидишь и пишешь исктуственный интелект, как из двух документов, один собрать...
именно поэтому...
именно поэтому...
Не прокатит, пользователь очень капризный и ленивый (не спрашивайте подробностей).
Хотелось бы этого избежать в первую очередь, все гениальное в простом.
Хотелось бы этого избежать в первую очередь, все гениальное в простом.
вот и ответ - один пользователь - один сервер - одна база
вот и ответ - один пользователь - один сервер - одна база
Это точно плохое решение - проверено. бывает и 1 секунды много. А если серавачок призадумается чуток - то злобная толпа юзверей мигом залочат что не следует.
В локальной и не очень сети есть только 1 вариант лочки - через центральный сервер (без деления на области видимости).
Причем совсем не обязательно использовать для лочки доминошный сервер - начиная от банального файла открытого на запись типа \\server\share\dbID_Doc_ID.lock
И заканчивая url get какого-ть http сервачка c php и базой структуры uid,user,LastLockTime . благо этиф-ции легко вызвать из LS\LS2J.
Самое простое - не позволять редактировать 1 документ обоими.
Если требуют что бы был версионинг - то его то же не сложно сделать.
А если капризным нужен версионинг - то значит они сами должны обладают умом и сообразительность что с этим делать... Хотя... о чем это я?
всё бы ничего, если бы никогда не было нештатных ситуаций - возможно "подвисание" лока, со всеми вытекающими ...
Инфу о локе надо хранить в домине. И желательно так, что бы авария/перезагруз да и любое нарушение логики lock-unlock снимало ранее установленные локи автоматом.
А это значит, что локи надо хранить в памяти лок-сервера, а не в доках на нём же. Это, конечно, если все работают с одними репликами или в локалке (или в достаточно широком канале, если юзера разбросаны по миру).
Проблема не так проста, как кажется. Универсальное решение на все случаи жизни реализовать проблематично.
Особенно если ведётся работа с разными репликами, а уж если изменения затрагивают цепочки доков по бизнес логике - тем более.
В общем, разруливается каждая конкретная ситуация по своему.
Более вероятная ситуация - юзер ушел в отпуск, открыв док
ИМХО - совсем не связанный с домино функционал.
Как то столкнулись с производительностью лочки на домино серверного агента при обработке большого кол-ва доков. - этож на каждую операцию на доком надо минимум раз найти и сохранить локдок. RPC вызовы на удален. сервер при этом как то не очень вдохновили
по http 500 байт на лочку и на 512 к канале хорошо жили.Но эт все физика - главное для комрада:
а вот вариант с пхп мне нравиться. Достаточно интересный способ, легко реализуем...
не понятен момент с "репликами" (по всему миру?) есть репликID базы, он для базы уникален по всем репликам. если реплики идут "по миру". то добавляем зачатки искуственного интелекта в базу лока, где отслеживается на каком сервере делался лок документа + накладываем "сверху" запас на репликацию изменений на другой сервер.
с цепочками тож не понятно. Ты собираешься лок документа отслеживать или репликационные конфликты разгребать? как я уже сказал, если в алгоритм лока добавить время для репликации, то всё становиться в норму. Если так беспокоишься о "цепочках", то стоит при обработке цепочек добавить алгоритм, который перед внесением изменений, сначала проверит лок для "цепочки", если документы свободны, то лочит их, изменяет, анлочит. Если хоть один документ залочен, то пользователю сообщаешь, чтоб он сходил покурил, и попробовал минут через пять.
также анлок всех документов при "проблеме" делается элементарно, тупо база зачищается и всё.
не понятен момент с "репликами" (по всему миру?) есть репликID базы, он для базы уникален по всем репликам. если реплики идут "по миру". то добавляем зачатки искуственного интелекта в базу лока, где отслеживается на каком сервере делался лок документа + накладываем "сверху" запас на репликацию изменений на другой сервер.
с цепочками тож не понятно. Ты собираешься лок документа отслеживать или репликационные конфликты разгребать? как я уже сказал, если в алгоритм лока добавить время для репликации, то всё становиться в норму. Если так беспокоишься о "цепочках", то стоит при обработке цепочек добавить алгоритм, который перед внесением изменений, сначала проверит лок для "цепочки", если документы свободны, то лочит их, изменяет, анлочит. Если хоть один документ залочен, то пользователю сообщаешь, чтоб он сходил покурил, и попробовал минут через пять.
также анлок всех документов при "проблеме" делается элементарно, тупо база зачищается и всё.
Обучение наступательной кибербезопасности в игровой форме. Начать игру!