We have 3 replica’s on 3 different servers(Server A, Server B and Server C). Documents are replicated by adding or removing the specific servers from the reader fields. Replica on server A contains all documents. Replica on server B and C contain a subest of document but have the same access. Now server B serves as a sort of hub between server A and C(we need that hub for security issues). Now, when access is removed from a document for the replica on server B and C it replicates to the replica on server B and thus is removed. But it is not removed from the replica on server C. The question is, why? As far as I know, when a server is unable to read a document it is treated as a deletion. Why doesn’t that deletion replicate to the replica on Server C?
Subject: RE: Selective replication by readers field
Thanx for your response!
Yes, I figured as much.
The mystery here is “What happens to the document if through replication the server doesn’t have access to the the document anymore?”. Is it treated as a deleted document? In that case it should also replicate to the replica on Server C. Or is it still there but unreadable by the server and thus not replicated to replica on Server C (seems to be the most likely one)? Any ideas?
Subject: RE: Selective replication by readers field
Thats a nice theory, and I agree. But when I replicate I really do see “The replicator deleted 1 document(s) in server B db.nsf”! That message is misleading then?
Subject: RE: Selective replication by readers field
Thanx guys! I guess this one falls into the category of “bad practice” Although I still find it strange that you can create a situation like this without any error, warnings or whatsoever.
Subject: RE: Selective replication by readers field
Well… if leaving the documents in C even though they are gone from B was what you were actually trying to accomplish, you’d probably be ticked off that it was issuing all those unnecessary warnings. And who knows?.. There might be a use case for that out there somewhere
Subject: RE: Selective replication by readers field
Willy is right on. There’s a difference between “removal”, which does not leave behind a stub, and “deletion”, which does. Another place you see removal is in the fixup task, where damaged docs are removed from an NSF but no stub is left behind so that the doc could possibly replicate back from another replica.
Now, clearing replication history on C and forcing a replication from C to B may cause C to remove the document when it notices that it no longer has access, but I’m pulling that trick out of the dim recesses of memory and I’m not all that confident that it still works (or ever worked, for that matter).
To get around this, what you need to do is remove access for server C first, in a separate operation. Then, after the doc has been removed from C, you remove access for server B. Trouble is… there’s no easy and sure-fire way to guarantee that the removal has occurred on C before you remove access for B.
Since you’ve indicated that you can’t have C replicate directly with A for security reasons (an explanation of why someone thinks this is necessary might help us give you additional alternatives!), can you set up an A2 server that has the same access rights as A, but both B and C can replicate with it?
Although I still find it strange that you can create a situation like this without any error, warnings or whatsoever.