Массовое "replication Or Save Conflict"

IsAvailable · 26.02.2007

Сервер и клиенты - 6.5
На сервере есть база. Написанная в конце прошлого века и работавшая с тех пор без проблем.
С недавних пор (порядка недели, чуть больше) начались непонятные вещи - после открытия документа и попытки его сохранения - вываливается "Replication or Save conflict". При этом:

1. Пользователли работают с базой напрямую, без реплик.
2. С одновременным открытием документа разными пользователями не связано (тестировал - создавая, изменяя документ лично)
3. Агентов, способных порождать подобные конфликты, обнаружено не было.
4. Сжатие и фиксап базы не дали никаких результатов.
5. На локальной копии работает всё "на ура".
6. В базе порядка 33 тыс. документов (2,5Гб)
7. Конфликты возникают при работе с различных компьютеров и учетных записей.
8. С сервером никаких изменений не производилось.

С чем подобное поведение может быть связано? Может, кто-нибудь знает?

puks · 26.02.2007

А в дебагере можно пройтись, чтобы понять на каком этапе появляется ошибка?
А время нигде не менялось?

morpheus · 26.02.2007

Для: IsAvailable
Lock / UnLock документов попробовать дописать
2. - проверить

возможно у когото реплики , локально или удалённики?

IsAvailable · 26.02.2007

Для: puks
1.
Дебагером излазил уже всё вдоль и поперёк %)
Вся гадость ситуации в том, что ошибка не стабильна!

Чаще всего возникает в такой ситуации: по нажатию на кнопке в документе заполняются поля и в конце вызывается:

Call doc.Save(True,False)
Call uidoc.Close

Перед сохранением отрабатывает процедура, которая еще дописывает кой-чего в документ, потом отрабатывает процедура перед закрытием, в которой правда снова есть doc.Save(True,True), которая проставляет ссылки на ответные документы, если такие есть.
После этого наступает собственно событие закрытия и вываливается ошибка.
Можно, наверно, создание ответных документов в событие сохранения засунуть... Но опять же возникает тупая мысль: почему до этого 10 лет работало? почему на локальной копии не валится? etc.
2.
Время, на сколько знаю, не менялось, но нужно у админов домена еще уточнить. Если всё же менялось, то какие профилактические меры можно предприянять? Что можно сделать в случае, если время просто случайно сбойнуло?

Для: Morpheus
В свойствах базы проставить "Allow document locking"? Врублю сейчас, завтра посмотрю на эффект, но что-то особым оптимизмом не страдаю на этот счет (
По поводу реплик - опять же, на сколько мне известно, реплик нет, но пользователей много, база существует давно, так что всякое может быть, наверно... В настройках репликации поотрубал все Receive'ы на вкладке Advanced. Может еще чего где отрубить можно?

morpheus · 26.02.2007

(IsAvailable @ 26:02:2007, 16:58 )В свойствах базы проставить "Allow document locking"? Врублю сейчас, завтра посмотрю на эффект, но что-то особым оптимизмом не страдаю на этот счет (

[snapback]57331" rel="nofollow" target="_blank[/snapback]

[/quote]
- и не надейтеся, Lock придёться писать самому вручную при открытии документа, это уже Lotus Script


(IsAvailable @ 26:02:2007, 16:58 )doc.Save(false,True)

[snapback]57331" rel="nofollow" target="_blank[/snapback]

[/quote]

Constantin A Chervonenko · 26.02.2007

Если в событиях формы есть свой явный doc.Save, то "..save conflict" практически гарантирован. Единственно где он допустим - в PostSave (если версия старше 5).
Причина: UI отслеживает дату background-документа. И если между Open и Save она менялась - диагностируется этот самый конфликт.

puks · 26.02.2007

Можно их синхронизировать через refresh/reload методы. Ведь мы не знаем, что там делается с doc и uidoc между открытием и закрытием. И иногда без doc.save не обойтись. Но действительно, чем больше таких сохранений, тем более вероятен конфликт.

IsAvailable · 26.02.2007

(Morpheus @ 26:02:2007, 18:12 )Lock придёться писать самому вручную при открытии документа

[snapback]57333" rel="nofollow" target="_blank[/snapback]

[/quote]
Хм... Можно поподробнее? Отслеживать на квериопен, открыт ли уже документ или нет? как это проверить? Ну и если открыт кем-то, то соответственно выдавать сообщение и посылать конкурирующего пользователя... Так?

А почему False, True? Если первый True, то тогда ведь по идее конфликты решаются автоматически в пользу более новой версии документа... Разве нет?
Но всё равно в моём случае не помогло это... =\

Для: Constantin A Chervonenko
Вот этого не знал. Хотя такой принцип довольно логичен. Можно, конечно, привести базу "к нормальному виду". Почистить всё это, переписать...
Я не против заняться этим, вот только смущают меня 2 вещи:
1. На локальной копии никакой последовательностью действий вызвать конфликт такой мне не удалось
2. До сих пор 10 лет база работала без подобных ошибок

IsAvailable · 26.02.2007

(puks @ 26:02:2007, 18:35 )Можно их синхронизировать через refresh/reload методы

[snapback]57338" rel="nofollow" target="_blank[/snapback]

[/quote]
В смысле? После рефреша бекэнд и фронтэнд синхронизируются?! Что-то не понял...

P.S. Сорри, с самого начала не уточнил, но похоже, и так поняли меня правильно: doc и uidoc - это NotesDocument и NotesUIDocument соответственно одного и того же документа. То есть фактически
doc = uidoc.Document

Кстати, еще обратил внимание - когда к документу аттачится файл (есть там РичТекст поле для этого), то вероятность получить этот самый конфликт практически равна 100%. Еще попробую полазить в этом направлении, но не встречалось мне до сих пор никаких встроенных реакций в программном коде, реагирующих на вставку аттачей.

puks · 26.02.2007

Почитай в хэлпе про эти методы. Там реализация зависит от версии. Заметь про richtext!!!

Reload method

Refreshes the current document with any changes that have been made to the corresponding back-end document. Refreshing the current document updates its representation in memory, as well as visually on the workspace, to reflect the changes that have been made to the back-end document.

Defined in
NotesUIDocument

Syntax
Call notesUIDocument.Reload( )

Usage
This method is valid only when the document is in Edit mode.
Modifications made to non-rich-text items on the back-end document accessed through the Document property appear on the current document immediately. Modifications made to non-rich-text items on the corresponding back-end document accessed from the front-end document but not through the Document property (for example, if you use GetDocumentByUNID) do not appear immediately unless the AutoReload property is True. To cause the modifications to appear when the AutoReload property is False, call Reload or close the document and reopen it.
Modifications made to rich-text items on the back-end document do not appear on the current document until it is closed and reopened.
Modifications made to items on the corresponding back-end document accessed outside the front-end document (for example, by an agent or another user) do not appear unless the document is closed and reopened.

Есть еще свойство AutoReload влияющее на это.

Refresh method

Refreshes a document. When you refresh a document, its computed fields are recalculated.

Defined in
NotesUIDocument

Syntax
Call notesUIDocument.Refresh( [ IncludeRichTextItems ] )

Parameters
IncludeRichTextItems
Note This parameter is new with Release 5.
Boolean. Optional. Specify True to include all rich-text items in the back-end document. Defaults to False.

Usage
This method is valid only when the document is in Edit mode.
This method is useful when the value of a computed field depends upon the contents of another field on the document.

IsAvailable · 27.02.2007

Для: puks
То есть можно попробовать AutoReload в False поставить и Reload сделать...
Если правильно понял - Релоад перезаписывает в фронтэнде все поля значениями из бэкэнда.
Предполагаю, что после этого doc.save(True,False) будет аналогичен uidoc.save
Так?

Про IncludeRichTextItems что-то не совсем понял... Если True, то включает их в бэкэнд? А что значит "включает"? То есть как практически изменяется метод в зависимости от этого параметра?

2All
Выяснил, что может быть кол*цензура*ие времени на сервере в пределах до 5 минут. Больше 5 минут в последнее время не было. Может ли 5 минут повлиять на поведение базы в Лотусе?

Constantin A Chervonenko · 27.02.2007

IsAvailable сказал(а):
2All
Выяснил, что может быть кол*цензура*ие времени на сервере в пределах до 5 минут. Больше 5 минут в последнее время не было. Может ли 5 минут повлиять на поведение базы в Лотусе?

Может, если у тебя репликация каждые 5-10 минут

puks · 27.02.2007

А чего такие большие кол*цензура*ия? Разве нельзя синхронизировать с инетом?

puks · 27.02.2007

По поводу refresh/reload. Про AutoReload я написал, так как, если оно будет выкл., то без этого reload обновления не будет.
По моему опыту, тебе надо поиграться с этими методами в паре, так как результаты у меня получались разные. Кроме того, тебе тяжело что-либо посоветовать, так как мы не знаем логики работы с doc и uidoc в твоей форме.

Но направление, по крайней, мере ты получил.

IsAvailable · 27.02.2007

При переносе на другой сервер работает без ошибок.

Наверно, так и сделаю - перекину базу на другой сервер. Но всё равно не понятно, из-за чего мог произойти подобный сбой...
Попробовал использовать Reload перед сохранением - результата не дало.

puks · 27.02.2007

А что значит при переносе? Как ты переносил?
А сервера по конфигурации одинаковые?

IsAvailable · 27.02.2007

Нда, не совсем корректно выразился...
Перенос - New Copy.
Серверы - тот, С которого переносил - основной в домене, тот, НА который переносил - обычный сервер в этом домене.
Причем попробовал New Copy сделать на тот же сервер, где и было, но под другим именем - ошибки по-прежнему остались.
Попробовал удалить порядка 90% документов + фиксап + компакт - ситуация не изменилась.

puks · 27.02.2007

Странно все это. Вообще New Copy (или New replica) часто решает многие проблемы, так как база получается без дырок, индексы пересчитываются и стабы удаляются. Надеюсь, что ты понимаешь, что New Copy не создает реплики базы.
Думал, что может быть база у тебя большая и тп. Но ты же удалял документы и сжимал базу ...
А ты транзакции на этом сервере используешь?

Но по логике, я бы все-таки шел от кода. Попробуй скомбинировать все сохранения в одно событие.

IsAvailable · 27.02.2007

Вот-вот... Я тоже репу чешу и думаю "странно это всё как-то..."
Что копия и реплика - разные вещи - это уж я в курсе В-)
Транзакции - не используются.
ODS version: 43 - так что по идее и с размером в 2Гб проблем не должно быть. Да и в самом деле - чистил её основательно...

С кодом - попробую. Просто база юзабельняа и нужны быстрые и надежные решения %)
Пока на другой сервер перекину, а параллельно с кодом поковыряюсь.

IsAvailable · 01.03.2007

В общем, похоже, локализовал причину конфликтов:
На событии QueryOpen стоит обработка, заключающаяся в добавлении "смотрителей" в документ.
Что-то типа

Код:

Set doc = Source.Document
If  Instr(doc.GetFirstItem( "Readers" ).Text, Session.CommonUserName)=0 Or doc.GetFirstItem( "Readers" ).Text="" Then		 
Set dt = session.CreateDateTime(Now)
Set item = doc.GetFirstItem("Readers")
Call item.AppendToTextList(session.CommonUserName+Chr(9)+dt.DateOnly+" "+dt.TimeOnly)
Print "Запись в протокол доставки"
Call doc.Save(True,False)
End If

Readers - текстовое поле
Соответственно, после этого вот doc.Save(True,False) этот же документ открывается. При сохранении после изменений уже обоснованно ругается на конфликт сохранения.
И вот даже не знаю, как лучше в данной ситуации поступить... Переоткрывать документ что ли после первого открытия... Или есть способ лучше?

Все сервисы Codeby

Поиск

Поиск

Массовое "replication Or Save Conflict"

IsAvailable

puks

morpheus

IsAvailable

morpheus

Constantin A Chervonenko

puks

IsAvailable

IsAvailable

puks

IsAvailable

Constantin A Chervonenko

puks

puks

IsAvailable

puks

IsAvailable

puks

IsAvailable

IsAvailable