If two clients simultaneously request replication of the same object (or if a second request is made any time while the first request it being processed), one one the replications will fail with the error "destination object exists" from the repository. One way this can happen is two parallel evaluations trying to replicate a shared model import.
Handling this should be transparent to users of the higher-level replication API (used by vrepl, the evaluator, and others). The server will need to keep a table of in-flight replications and have subsequent requests for the same object block until the preceding one completes. We probably need to have the server side ("Replicate" in Replication.C) block and return only after the replication attempt that started first completes. Unfortunately, this will take up a thread on the server. It's tempting to think that the server could instead return an indication to the client that a parallel replication of the same object is in progress and then have the client poll for the completion of the replication, but I think that will make it harder to handle the case where a replication attempt fails.
What should we do if the first replication attempt fails with an error (e.g. the repository we were replicating from reboots) and there are blocked subsequent attempts to replicate the same object? It wouldn't be correct to have them all fail just because the first request failed. A later request might have a different source repository that is still on the network. So if the first replication attempt fails an there is another one for the same object that has been blocked it should wake up and attempt to replicate the object.
Log in to post a comment.