Cross-posting from dev, since this may be a better forum: How about something like this to implement transactions?
During an 'transactional bulk write': - For each document in the transaction, - Attempt to create a new rev of the document, specially flagged so it doesn't show up in views, document fetches, or replications (return the last version of this documents instead). While hidden, There would probably be some way to retrieve them, like the way you retrieve conflicted versions currently. - This rev SHOULD be examined when checking for conflicts with subsequent writes (so no new writes to the document can happen while the transaction is in progress - they return with a conflict error). - If all of the documents in the transaction are created successfully (pass document validation, don't conflict with earlier revs), remove the flags from these revisions (therefore becoming standard revs in the database). If not, remove these newly created revs. This would sort of give a loose form of two-phase commit that should work over sharded databases. There's obviously a higher performance cost - it's equivalent to two writes (once to write these 'shadow' revisions, and once again to remove the flags on success or prune the revisions on failure). And clients won't be able to write to any of the documents in the transaction until it completes (effectively locking them for write), because they won't be able to see the latest version. But it would probably achieve the effect that most people want. And naturally, it wouldn't be the default bulk_write behavior (given the cost and limitations). For Multi-master replication, this really shouldn't change anything. The hidden rev won't replicate to other masters, but if another master attempts to replicate a version over the top of the hidden rev, it's treated exactly the same way as a standard multi-master conflict; it will be flagged as conflicted, and one of them will show up in views. On Sat, Apr 4, 2009 at 4:54 AM, Antony Blakey <[email protected]> wrote: > > On 04/04/2009, at 9:48 PM, Andrius Juozapaitis wrote: > >> Antony: I was assuming (given a replication scenario) that I'll be >> using one node as a master, and spring would only access this node >> for updates, while the others would be used for reading only. > > Certainly for very specific architectures there are workable solutions - > yours being one of them. My goal is to encourage the most general solution > possible, as in my transactional git branch. > > If you eliminate relplication then you can completely wrap CouchDB's API and > apply both significantly extended and quite different semantics (of course). > In fact, this is how I think the app-server like features of CouchDB should > be done, rather than the current model. The problem is that CouchDB doesn't > expose enough to do that wrapping once replication is involved. > > Antony Blakey > -------------------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > Don't anthropomorphize computers. They hate that. > > >
