Hi
One of our Notes databases is replicated every 15 minutes on 5 servers in different locations. Every thing works fine most of the time, except documents added in one replica almost always become replication conflict in other DBs. All the forms in the database design have merge replication enabled. All the servers are R6 servers and ODS of databases is 43.
Can anyone suggest what, if anything can be done?
regards
Alpna
Subject: Annoying replication conflict problem
In 90% of the cases, replication conflicts occurs because the database wasn’t properly “thought” and designed to make sure 2 people aren’t modifing the same document (and specifically the same fields) at the same moments.
Think about it:
In most cases, Notes is used to handle workflow (a document is modified by a chain of people, one after another) or certain sections of a document are modified by certain people with a given right and a different section by someone else, etc.
It is very rare that you have a situation where a document will be modified by 2 different people within the same replication slice. If you tell me that the servers are even replicating at as low as every 15 minutes - this should be VERY rare.
If it is not, then it probably means:
a) an agent was scheduled to run on the backend, modifying ALL the documents over and over, thus causing a conflict EACH time a user makes a modification on a different server than the server running the agent
(if you have agents running, make sure they ONLY run centrally on ONE single server, and ideally, during night time).
or
b) the design of the application was not thought properly - try splitting the info between various sections or even different documents, so that you know, in the work process, that they aren’t SUPPOSED to be modified by 2 people at the same approximate time.
Record locking is a neat feature in theory, but in pratice it means it can cause a lot of side effects: a document may become UNMODIFIABLE because someone else on a different replica has locked it and never unlocked it after (a local user for instance, who goes out travelling) - and it should only be used, IMHO, when you have a unique central source of information that should only be modified at one place.
These cases are quite rare in a Notes model because, after all, Notes is primarly used to manage knowledge, not to manage financial data or stock control.
Good luck!
Nicolas Abesdris / PCLP
Quintessence e-solutions Inc.
Subject: New Feature in ND6 - Document Locking
Locking documents
If you have Author access or higher to a document, and document locking is enabled for the database, you can lock the document on any replica while you are working in it. Locking a document allows you to lock out others who have editing access so they cannot modify the document at the same time you are, even if they are working on a different replica. This prevents two or more people from making changes to the same document and then saving it at the same time causing replication and save conflicts, where Notes doesn’t know which edits to save. Even Managers of a database cannot edit a locked document. However, Managers can unlock documents that are locked.
When you are finished editing the document, you can then unlock it, allowing others to modify the document.
Note You must be using Lotus Notes 6 and Lotus Domino 6 to use the document locking feature. You must also have an administration server defined in the access control list (ACL). If you do not have an administration server defined in the ACL, you receive an error from Notes.
To enable document locking in a database, you must have Manager access.
Choose File - Database - Properties.
Click the Basics tab, and select (or deselect) “Allow document locking.”
Subject: RE: New Feature in ND6 - Document Locking
Thanks for your response - Edmund. I will give ‘Document Locking’ a go and hope that will work.
I am just curious though about “even if working on different a replica” How does the DB/System/server determine if a particular document is being edited on a different replica?
regards
Alpna
Subject: RE: New Feature in ND6 - Document Locking
Once enabled, you will find that every time you edit a document, the status bar indicates, “Document successfully locked.” Likewise, when saving/closing a document, “Document successfully unlocked” is written to the status bar. This requires no extra steps for your users. Behind the scenes, whenever the document is put in/out of edit mode, two fields are written to: $Writers and $WritersDate. The first field is a read/write access names field, the same as an AuthorNames field. The second field is a time/date stamp. These fields are used to let the system know that the document is locked. When unlocked, these fields are blanked out.
Note that you can alternatively lock/unlock a document via the Actions menu (or right-click and choose Lock/Unlock from the pop-up menu). If you lock a document this way, it remains locked until you unlock it. If you lock a document implicitly by simply editing the document, it unlocks automatically when you come out of edit mode.
If the database has no replica copies, then using this feature is trivial. But let us assume that there are replica copies on multiple servers. In that case, when you try to edit a document, the server makes a call to the administrative server to make sure that this document is not locked. If it is locked, you are given an appropriate error message. If it is not locked, then you are given the lock. For this reason, it is critical to the smooth functioning of this feature that the servers can all communicate with the administrative server easily. If they cannot, or if that communication is slow, then your users will experience a host of problems, from incomplete error messages to an inability to edit/save the document.
Note that the feature can handle local and dial-up access. It gives the user a message to the effect that it will try to synchronize the edits when connected, and will generate a rep/save conflict only if necessary. The user will get an email message with the results of this attempt.
Subject: RE: New Feature in ND6 - Document Locking
Hi Edmund.You seem to have a good idea about the document locking feature. I have experiemented with in test and found to be a nice feature. The one problem I have with it is that what happens if we have only one form that we want to enbale document locking. Currently it covers all forms. Sorry to ramble but just thought I’d throw that out there for Lotus.
My real question is that we have a multiple replica environment. Weird thing is 1 of the replica’s seem’s to have document locking enabled. The ultra wierd part that stumps me is that the Database Property for allowing Document Locking is NOT selected on that replica and all the others??? I don’t know where this is coming from. Do you have any ideas? I have only read that in order to use document locking that property must be selected…but what if its not and its still doing it…ahhhh
Well appreciate your time and any comments you have.
Thanks
Reid