Блокировка документов

[VladSh]

Т.к. ссылки больше не работают, решил расписать концепт блокировок, полностью исключающих возникновение конфликтов.

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

1. Распределённый вариант.
По умолчанию в поле вписывался ТЕКУЩИЙ сервер. С 2001-го по 2010-й у нас работала самописная блокировка - создание документика в специальной блокировочной базе. Причём эту базу даже не нужно было реплицировать, достаточно было разбросать эту базу по серверам - на каждом сервере в этой базе создавались блокировочные документики, по чисто созданным и изменяемым на нём документам. То есть на каждом сервере изменялся всегда свой уникальный набор документов, чем полностью исключались конфликты репликации.
2. Централизованный вариант.
В глобальных настройках СЭД была настройка "Переводить документ на административный сервер", которая после создания и отправки документа по маршруту сразу же единоразово меняла сервер на административный. В таком случае все документы фактически изменялись только на административном сервере.
За исключением пары случаев, использовался 1-й вариант, - нагрузку по обработке документов таким образом можно было "размазать" по серверам.
3. Можно было наворотить логику по подмене сервера в поле Server, в зависимости от типа документа и т.п., определяя, на каком сервере (или кластере) данная разновидность документов чаще всего обрабатывается, но мы не стали тогда этим заморачиваться...

При появлении штатной блокировки в Lotus мы постепенно переделали код на неё (Hard-lock + Soft-lock).
Выбор штатной блокировки был обусловлен её достоинствами:
- при падении Notes документ автоматически разблокируется, что позволило полностью отказаться от ручных разблокировок документов в критических ситуациях;
- сильно упростился анализ на блокировку в UI и, соответственно, уход от конфликтов сохранения;
- штатный механизм работает гораздо быстрее самописного.
Процесс исследования и перехода занял несколько лет, пока все баги не были выловлены (можно поискать по форуму - все проблемы описаны достаточно подробно).

1. Распределённый вариант.
Т.к. MasterLock-сервер завязан на административный сервер (проблема была подробно описана здесь), пришлось:
- отказаться от репликации ACL баз - перешли на статический ACL;
- установить в каждой нашей базе каждого сервера административным ТЕКУЩИЙ сервер.
Таким образом на каждом сервере мы смогли блокировать свой набор документов, также, как это было и с самописной блокировкой. Т.е. основное требование - полностью исключить конфликты, - было выполнено.
2. Централизованный вариант.
Работал без вышеуказанных проблем и ограничений, но из-за большой нагрузки на сервер обработки мы полностью перешли на распределённый вариант, несмотря на все ограничения.

В итоге, при любом варианте блокировок (самописная или штатная) при наложении на собственный "транзакционный" механизм работа СЭД была абсолютно бесконфликтна.

Случай падения одного из ЦОД'ов тогда не рассматривался, т.к. не было критических прецедентов. Но даже в такой реализации при желании можно предусмотреть обработку документов "потухшего" сервера другим сервером, т.к. решение обрабатывать документ или нет решается на уровне скрипта.

 

[savl]

Про ссылки:

Handling of conflict situations (UI)

IdeaSpace:

Ссылка скрыта от гостей

/

Ссылка скрыта от гостей

Tags:

Ссылка скрыта от гостей

,

Ссылка скрыта от гостей

,

Ссылка скрыта от гостей

,

Ссылка скрыта от гостей

Idea Author:

Ссылка скрыта от гостей

on 08 Jun 2010
Status: Open
Linkage:

Ссылка скрыта от гостей

/

Ссылка скрыта от гостей

Situation: A user opens the document, reads it, at this time an agent or another user changes the document, then the user goes into edit mode, change the document, saves it and gets a warning: "Another copy of this document was saved while you were editing it. Save your changes also as a Save Conflict document?".
In some applications, the user should not have the right to create conflict - in such applications are unacceptable.
I propose to change the working principle, ie, alert the user at the very beginning (when he translates the document into edit mode) that the document was changed, then the need for this message will disappear. The best implementation would be in translating the document into edit mode (for example, by double-click) to get the document from the database again (recent Instance) and substitute it in Source.Document in Querymodechange. Thus, if the document has changed and it is not terrible, because the translation into edit mode, we will always have actual data. If the document is changed at this time, then give the message that the document is now changed by another user, and to prohibit a transition to edit mode, ask to perform this operation later.

To accelerate the opening of certain documents (if someone would need such a regime), can make it optional with the system items, such as SaveOptions, ie:

• receive new Instance before going into edit mode;
• display a message about a conflict situation on save (as it is now).

---

1)

Ссылка скрыта от гостей

(08 Jun 2010)
I described the reasons why I propose. This is indeed a problem and it can be solved quite elegantly.
Serious question, so I'd like to see the reasons why you vote against it.

2)

Ссылка скрыта от гостей

(09 Jun 2010)
I believe the save conflict just as likely to be generated as a result of the document being changed elsewhere after the document was opened in edit mode. If document locking is enabled and a user opens a document in read mode they get a warning when they switch the document to edit mode that the document has changed and they should close and re-open the document.

3)

Ссылка скрыта от гостей

(10 Jun 2010)
The first sentence was not able to translate ...

"If document locking is enabled and a user opens a document in read mode they get a warning..."
This I know - this is not the situation. The situation, of which I speak (described in first paragraph) is indeed possible, that is very bad.
For some applications, the conflicts are not allowed in principle, this message allows the user to perform actions not provided for the application and the developer can not affect it, which is also very bad.

Problems of locking mechanism (UI)

IdeaSpace:

Ссылка скрыта от гостей

/

Ссылка скрыта от гостей

Tags:

Ссылка скрыта от гостей

,

Ссылка скрыта от гостей

,

Ссылка скрыта от гостей

,

Ссылка скрыта от гостей

,

Ссылка скрыта от гостей

,

Ссылка скрыта от гостей

,

Ссылка скрыта от гостей

,

Ссылка скрыта от гостей

Idea Author:

Ссылка скрыта от гостей

on 08 Jun 2010
Status: Open
Linkage:

Ссылка скрыта от гостей

/

Ссылка скрыта от гостей

1. In the present implementation the document is locked when double-click, that is, before the commencement of Querymodechange! This is wrong - on Querymodechange there are some conditions for which are not permitted to translate the document into edit mode.
I propose to block the document between Querymodechange and Postmodechange, while in edit mode, the document should be translated only if the document was blocked!
If suddenly you need to block the document before, it can be done elementarily programmatically by calling notesDocument.Lock() on Querymodechange.

2. If the document has been blocked by the current user and will re-lock (an attempt to translate the document into edit mode), then the document should not explicitly blocked and translated into edit mode, rather, it is not true, because document at the same time could be changed by another process from the same user, such as background agent. If you give to save the document, the data entered by another process will be replaced by the current instance.
Ideally, there should be a link with

Ссылка скрыта от гостей

idea, or should warn you that "the document is changed by another process..."


3. Lock indicators:

• If notesDocument.Lock() to pass an array of users, at the beginning LockHolders(1) for some reason a space (looks like this: " Value"), which complicates the analysis of blocking. It has been noted in 8.5.1.
• It was noted that notesDocument.Lock() returning True sometimes does not prescribe a document items $Writers and $WritersDate...
• If unlock (notesDocument.UnLock) LockHolders property is cleared immediately and the items $Writers - no.

This is all seen in the debugger and flies in the runtime...

---

1)

Ссылка скрыта от гостей

(09 Jun 2010)
I agree. Documentlocking was one of those features that was never fully implemented and a number of issues with its use often prevent it from being used in applications. unfortunately I don't see much chance IBM of devoting too much time to this unless it ties into locking of Xpage documents.

2)

Ссылка скрыта от гостей

(10 Jun 2010)
Thank you for your vote and comment, Peter.
1. If IBM will not support the UI, based on the Forms, you have officially reported this state, then we will not spend time with each other.
2. If XPages will work in the Notes client, and interface documents will be built on XPages, then the above problems are also possible, because mechanism, one(?) What meaning to write a second mechanism for XPages? In my opinion, better to refine the mechanism so that it worked in Forms and in XPages.

3)

Ссылка скрыта от гостей

(12 Jun 2010)
With the distributed state of Domion, it's hard to make a real document lock. I would rather see the ability to merge change and to realtime show updates on the form when content changes,. Similar to what flex can do.

4)

Ссылка скрыта от гостей

(15 Jun 2010)
Bruce,
Something can be solved as follows: {

Ссылка скрыта от гостей

}
but something like this (I wrote there something that just about): {

Ссылка скрыта от гостей

}
Any other ideas? Of course it would be great. Thank you!

А вот последняя, к сожалению, действительно потеряна, либо проблема с webarchive.