Варианты Блокировки Документов

Тема в разделе "Lotus - Программирование", создана пользователем Serduko, 8 окт 2014.

  1. Serduko

    Serduko Well-Known Member

    Регистрация:
    11 окт 2011
    Сообщения:
    174
    Симпатии:
    0
    Добрый день всем! Не могу выбрать вариант блокировки документов в СЭД, например: для фоновый задач (агентов) или для исключения одновременного редактирования документа (набора документов) двумя пользователями. Document Locking не очень нравится. Есть ли у вас какие нибудь оптимальные решения этого вопроса?
     
  2. ty3uk

    ty3uk Well-Known Member

    Регистрация:
    31 мар 2008
    Сообщения:
    169
    Симпатии:
    0
    вот не знаю кто что предложит. Но, боюсь, единственный способ, это отдать пользвоателю копию документа, потом, на "центральном" сервере, агентом, проверяются пользовательские изменения, и делаются соотвествующие изменения в нормальном документе. Насколько я понимаю, некоторые СЭД так и работают. Яже, в определённый момент, к сожалению, прохлопал это, а сейчас, что-то менять, это переколбашивать ядро по полной...
     
  3. savl

    savl Lotus team
    Lotus team

    Регистрация:
    28 окт 2011
    Сообщения:
    2.051
    Симпатии:
    146
    Оптимальных нет, есть куча идей, по крайней мере моя (еще не реализовывал):
    1. База для локов, реплика на все сервера. Скорость реплики 1-2 секунды (ну да в идеале, кластер хорошее решение)
    2. При открытии проверять наличие документа-лока, ключ поиска UNID открываемого дока.
    3. Если есть - сообщение или открытие только на чтение, если нет - создать.
    4. При закрытии документ либо удалять, либо метить к удалению, чтобы его другой пользователь не нашел.

    Все фоновые задачи по изменению документов должны идти или ночью, или в минимально загруженное время.
    Выполнятся только на одном из серверов реплики.
    Перед обработкой документа проверить открыт ли он кем-либо через базу локов.
    При save использовать лучше связку, на всякий случай:
    Код (LotusScript):
    if doc.Save(false, doc.isresponse) then
    priint "save"
    end if
    Не знаю, конечно, сильно ли это снизит конфликты, но возможно...
     
  4. Serduko

    Serduko Well-Known Member

    Регистрация:
    11 окт 2011
    Сообщения:
    174
    Симпатии:
    0
    В моем случае, система с центральным сервером, будет слишком ресурсно дорогой.
     
  5. savl

    savl Lotus team
    Lotus team

    Регистрация:
    28 окт 2011
    Сообщения:
    2.051
    Симпатии:
    146
    Да, тоже вариант, можно еще версионность прикрутить.
    Обработку изменений можно через очередь запросов.
    Вот только остается вопрос времени и скорости обработки...
    И для агентов это не подходит, но для пользователей вполне возможно.

    Добавлено: Serduko
    А без центрального сервера не получится... Опять же почему дорогой?
    Сервера уже есть, что мешает один из них приспособить для этого.
    Другое дело настроить реплики, это может оказаться не так просто.
     
  6. Serduko

    Serduko Well-Known Member

    Регистрация:
    11 окт 2011
    Сообщения:
    174
    Симпатии:
    0
    Дело не только в сервере и в репликах, да в общем и не в ресурсоемкости тоже. Сама логика меня смущает, как потом эти копии схлопывать на центральном сервере, может быть такая ситуация, когда данные будут противоречить друг другу? А если не схлопывать, то какой смысл вообще, тратить ресурс на сравнивание полей?
     
  7. savl

    savl Lotus team
    Lotus team

    Регистрация:
    28 окт 2011
    Сообщения:
    2.051
    Симпатии:
    146
    Ага, основная проблема...
    Кто последний тот и прав? с сохранением предыдущей версии...
     
  8. ty3uk

    ty3uk Well-Known Member

    Регистрация:
    31 мар 2008
    Сообщения:
    169
    Симпатии:
    0
    а это также как программная обработка репл.конфликтов. Сидишь и пишешь исктуственный интелект, как из двух документов, один собрать...
    именно поэтому...
     
  9. Serduko

    Serduko Well-Known Member

    Регистрация:
    11 окт 2011
    Сообщения:
    174
    Симпатии:
    0
    Не прокатит, пользователь очень капризный и ленивый (не спрашивайте подробностей).

    Хотелось бы этого избежать в первую очередь, все гениальное в простом.
     
  10. Kee_Keekkenen

    Kee_Keekkenen Well-Known Member

    Регистрация:
    5 сен 2006
    Сообщения:
    616
    Симпатии:
    4
    Хотелось бы этого избежать в первую очередь, все гениальное в простом.

    вот и ответ - один пользователь - один сервер - одна база :(
     
  11. rinsk

    rinsk Lotus team
    Lotus team

    Регистрация:
    12 ноя 2009
    Сообщения:
    795
    Симпатии:
    78
    Это точно плохое решение - проверено. бывает и 1 секунды много. А если серавачок призадумается чуток - то злобная толпа юзверей мигом залочат что не следует.
    В локальной и не очень сети есть только 1 вариант лочки - через центральный сервер (без деления на области видимости).
    Причем совсем не обязательно использовать для лочки доминошный сервер - начиная от банального файла открытого на запись типа \\server\share\dbID_Doc_ID.lock
    И заканчивая url get какого-ть http сервачка c php и базой структуры uid,user,LastLockTime . благо этиф-ции легко вызвать из LS\LS2J.
     
  12. rinsk

    rinsk Lotus team
    Lotus team

    Регистрация:
    12 ноя 2009
    Сообщения:
    795
    Симпатии:
    78
    Самое простое - не позволять редактировать 1 документ обоими.
    Если требуют что бы был версионинг - то его то же не сложно сделать.
    А если капризным нужен версионинг - то значит они сами должны обладают умом и сообразительность что с этим делать... Хотя... о чем это я?
     
  13. alexas1

    alexas1 Lotus team
    Lotus team

    Регистрация:
    10 апр 2014
    Сообщения:
    563
    Симпатии:
    214
    всё бы ничего, если бы никогда не было нештатных ситуаций - возможно "подвисание" лока, со всеми вытекающими ...
    Инфу о локе надо хранить в домине. И желательно так, что бы авария/перезагруз да и любое нарушение логики lock-unlock снимало ранее установленные локи автоматом.
    А это значит, что локи надо хранить в памяти лок-сервера, а не в доках на нём же. Это, конечно, если все работают с одними репликами или в локалке (или в достаточно широком канале, если юзера разбросаны по миру).
    Проблема не так проста, как кажется. Универсальное решение на все случаи жизни реализовать проблематично.
    Особенно если ведётся работа с разными репликами, а уж если изменения затрагивают цепочки доков по бизнес логике - тем более.
    В общем, разруливается каждая конкретная ситуация по своему.
     
  14. rinsk

    rinsk Lotus team
    Lotus team

    Регистрация:
    12 ноя 2009
    Сообщения:
    795
    Симпатии:
    78
    Более вероятная ситуация - юзер ушел в отпуск, открыв док :)
    ИМХО - совсем не связанный с домино функционал. Убить Билла Убить все - проще чем исключить нарушение логики (restart SMB\in memory table))
    Как то столкнулись с производительностью лочки на домино серверного агента при обработке большого кол-ва доков. - этож на каждую операцию на доком надо минимум раз найти и сохранить локдок. RPC вызовы на удален. сервер при этом как то не очень вдохновили :) по http 500 байт на лочку и на 512 к канале хорошо жили.

    Но эт все физика - главное для комрада:
     
  15. ty3uk

    ty3uk Well-Known Member

    Регистрация:
    31 мар 2008
    Сообщения:
    169
    Симпатии:
    0
    а вот вариант с пхп мне нравиться. Достаточно интересный способ, легко реализуем...

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

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

    также анлок всех документов при "проблеме" делается элементарно, тупо база зачищается и всё.
     
Загрузка...

Поделиться этой страницей