couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Sanford <>
Subject Re: Deciding on the structure of documents
Date Mon, 29 Mar 2010 01:58:22 GMT
On Sun, Mar 28, 2010 at 7:20 PM, Patrick Barnes <> wrote:

> For the single-document situation: What if multiple people reply to the
> same post at the same time? The first comment to reach couchdb would succeed
> in updating the document, and the second comment would result in an error,
> because the doc revision is now out of date. A single-document situation
> would require the application logic to handle a revision error, and maybe
> automatically resubmit. This solution does not scale well - the more traffic
> and the more comments a site receives, the more likely these revision errors
> will occur.

This brings up a question on an app I'm in the process of designing and I'm
wondering how it works in a multi-node situation.

In my app a document (almost literally a document actually) can have a
single caretaker. In some situations the owner can decide they no longer
wish to act as caretaker and offer up the document to others. That situation
is easy in that the role of caretaker is explicitly transferred. Or, they
can simply release "ownership" of the document.In that instance others that
are assigned the role of Caretaker in the system can then claim the document
on a first-come-first-served basis.

In a multi-node system w/ replication what happens if Caretaker D in the
Dallas office claims the document and prior to any replication occurring
Caretaker P in the Phoenix office also claims the document?

How can that sort of situation be handled? In a single-node system it's (not
quite) trivial to handle but in a multi-node system w/ a time delay between
replications that are not taking business logic into account that is
trickier and I don't have my head around it yet.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message