On Fri, Mar 13, 2009 at 10:42 AM, Wout Mertens <[email protected]> wrote: > On Mar 13, 2009, at 5:47 PM, Chris Anderson wrote: > >> On Fri, Mar 13, 2009 at 9:41 AM, Wout Mertens <[email protected]> >> wrote: >>> >>> On Mar 13, 2009, at 4:12 PM, Tim Parkin wrote: >>> >>>> I think all bulk doc changes were written somewhere and then only >>>> switched in once the last was successful.. so no locking. >>> >>> But then if a normal write comes in while the bulk doc is being >>> processed, >>> how did it know to fail that write/fail the bulk? >>> >> >> CouchDB updates are serialized, so if a normal write comes in during a >> bulk update, the normal write waits. Of course, all this is different >> if the bulk update is spread across multiple nodes. Crossing that >> bridge is part of the motivation for limiting the feature to skip >> conflict checking. > > Again out of curiosity, how would the spreading work? The bulk write would > go to ibrowse, which would then contact multiple couches and give each of > them some work? >
Something like that. Maybe leave out ibrowse / http all together and communicate using erlang messages. Alternatively, save the update to a local temporary database, ack the client, and then replicate the updates to the proper home. Chris -- Chris Anderson http://jchris.mfdz.com
