What happens during Server to server replication if reader access is revoked

Question

I would like to understand what happens in the following Lotus-Domino server to server replication scenario:

• Server A has a replica of A database.
• Server B has a replica of the same database.
• Both servers have manager access on the database, including the delete document privilege.
• The replicator process has just replicated A and B and all is in sync.
• The database contains a note that has a reader field where both servers are mentioned.
• On server A the entry for server B is removed from the readers field.
• Server A initiates the replication with B.

In this scenario I expect that server A will remove the document from server B. There are variations on the scenario, server C replicating with B, B initiating the replication with A.

I have an application that is build around this expectation, and it has worked well most of the time. But there are notes that remain on server B and are excluded from the replication process. The OID remains different. There are instances where the DSN is updated on both notes without any result in the replication process.

Answer 1

Actually, I disagree with AndrewB's answer. In my experience, it should work as per your expectations. Using readernames fields to control replication has been part of my standard arsenal for 15+ years, and I have found it far more reliable than the alternative of selective replication -- which is evil and should be avoided at all costs, but that's another story!

It is true that once the readernames field no longer contains the entry for serverB the note itself is invisible to serverB, but the fact that the note has changed is not invisible to the replicator. The replicator should notice this, determine that serverB no longer has rights to the document, and remove it -- without leaving a stub.

Have you tried clearing the replication history on both sides?

Answer 2

This is an easy trap to fall into, you should not use Reader fields to control replication between servers, they are fantastic to control users and groups but all servers in a replication group should always have access to everything.

The reason the documents are left/not updated on server B is that removal of the server B from reader field on the document makes it invisible to the server hence it has no idea that it has changed, or been deleted. The reason that the deletion on server A was picked up by server B is that deletion converts the document into a deletion stub which is little more than the UNID so readers field also go making the deletion 'visible' to server B. You can't even force server A to write to server B because server A will know that server B isn't allowed to see the document so a push replication will ignore the document in question.

Answer 3

IBM has created an SPR for this:

Problem Normally, when a server is removed from the reader field of a document, after scheduled replication takes place, the document is deleted from the server since that server no longer has access to the document. In some cases, when a secondary server is removed from the reader field of a document residing on a primary server, after replication occurs between the two servers, the document is not deleted from the secondary server as is expected. Enabling replication debug reveals the following error on the source server: "You are not authorized to perform that operation". Clearing the replication history and initiating replication from both servers does not resolve the problem. Upon further investigation, it was determined that the document on the secondary server had a higher sequence number which implies that it was updated more recently than the document on the primary server. Normally, when a document does not contain a reader field or if both servers involved in the replication are listed in the reader field of both copies of the document, a replication conflict will be generated when the document is modified on both servers before replication takes place. However, in this particular situation, since the secondary server does not have access to the document on the primary server, replication fails as is expected and a replication conflict is not generated because in order for a conflict document to be generated, both servers need to have access to the document.

Resolving the problem 1.) A short term solution would be to modify the document on the primary server so that its sequence number is higher than document on the secondary server. After replication takes place, the changes should replicate to the secondary server and the document should be deleted from the secondary server as is expected. 2.) A more permanent solution would be to prevent users and servers from making changes to the document on both servers at around the same time. Also, replicating more often should help reduce the chances of such a condition from occurring since changes made on one server will possibly replicate out before changes are also made on the other server. This issue issue is being tracked under SPR MKHS8MLQVD