Last week in our webinar on RavenDB, we mentioned that we have at least two RavenDB instances in each of our data centers and that we have each of them configured to replicate to all the others. One attendee asked how we handle replication conflicts.
First, we try to limit replication conflicts, by having all writes to a given database directed at a single RavenDB instance. We showed off our UI for managing that, and I have another post in the works describing the details.
But there are inevitably cases where there is a conflict. We have some automated processes that update content, so multiple saves in rapid succession are not unusual. We also have integration challenges with other systems, resulting in our receiving the same document multiple times at more or less the exact same moment. If our write master changes at an inopportune moment (either due to failover or an intentional change by an admin), we'll likely have a replication conflict.
As I mentioned in my post on read-only vs. read-write databases, our front end web apps aren't allowed to write to most databases, so they can't resolve the conflict. In any case, that would probably make things worse, given the number of front-end servers we have.
Fortunately, there's an easy solution for us. The nature of our data and our business means we always want the latest version of a document to win. The Replication bundle provides a hook to allow custom handling of replication conflicts on the RavenDB server. We simply compare the Last-Modified value of the existing document with that of the inbound replicating document. Whichever has the later date wins.
Here's the code for the LastInWinsReplicationConflictResolver: https://gist.github.com/2012016
Score another one for the simple extensibility provided by RavenDB.
