couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Carey <paul.p.ca...@gmail.com>
Subject Multi doc transactions
Date Mon, 09 Feb 2009 21:13:20 GMT
Hi all

Given that multi doc updates that succeed in spite of update conflict
seem to be the way of the future for CouchDB, I'm trying to understand
how best to ensure single node consistency.

Consider a meeting room in a virtual world - thousands of users, a
public API and any number of API clients.

The desired behaviour is simple - users book rooms for meetings and
meeting notification emails are sent to invitees.

A room can host only a single meeting at any one time. CouchDB will
help enforce this if we set the booking id to be a hash of the room
and meeting time. (For simplicity I'm assuming all meetings start at
the same time and have the same duration).

We also want to create invite docs when we create the booking. The
invites are used to send notification emails and they may be accepted
or rejected by users.

Using a bulk update that fails if any doc update conflict occurs, we
know that the booking and invites are saved safely together and that a
duplicate booking hasn't been created.

Using a bulk update that doesn't fail if any doc update conflict
occurs, we either
i) save the booking and invites, resulting in an update conflict if
the booking is a duplicate. If a conflict occurred, we delete the
invite docs. We also need to ensure that emails aren't sent to
invitees before we've had a chance to delete spurious invite docs.
ii) save the booking and if it succeeds, then save the invites. The
issue here is node failure after saving the booking, but before saving
the invites.

An extension to ii) to ensure consistency would be
1. save the booking doc with a state property set to "incomplete"
2. if the booking doc save succeeds, use the bulk update to save the
invites, and update the booking doc with state "complete".

It's not very elegant, but I think it should work. I'd love to hear
better solutions.

Paul

Mime
View raw message