couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Parkin <i...@timparkin.co.uk>
Subject Re: how to ensure transactions over multiple documents?
Date Fri, 03 Apr 2009 12:48:06 GMT
Andrius Juozapaitis wrote:
> Hey,
> 
> I think this question might have come up before, but I've not found a
> definite solution to the problem. I'm trying to model a simple
> shopping cart solution on couchdb, just to find out the solutions to
> the problems that have come to my mind so far. Let's say, I have 2
> types of documents, products and categories, where product may belong
> to multiple categories. I expect product to hold an array of category
> ids. A simple use case:
> 1) user A updates an existing product, and updates a category(-ies),
> say, increasing product count property
> 2) the same category at the same time is being updated by user B, by
> uploading an updated image to it
> 
> If the operations happen in this exact order (1,2), user B will get a
> concurrent modification warning, and will have to reapply his changes.
> 
> But what if the product gets updated, then the category gets updated
> with a new image, and then the product count is increased on that
> category? The last step will fail, and the data in the system will
> remain in (logically) inconsistent state. What is the common scenario
> to solve this type of problems (this is just an example, the actual
> application has way more and varied dependencies). I do have an
> application server (tomcat+spring) handling all the user interaction
> to couchdb through jcouchdb, so I am free to implement any type of
> solution in the appserver layer. Any suggestions will be very much
> appreciated :)
> 

Hi Andrius,

I'm afraid at the moment the only way of doing this is through a patch
submittd by Antony Blakey which reintroduces the old transactional
behaviour of bulk_docs.

I've been trying to work out an alternative way of dealing with this
which involves a form of distributed transaction i.e. creating a new
versioning system on top of couch's versioning system and using flags to
mark things as 'deleted' so that if a conflict is detected the flag can
be removed. However this solution still leaves potential opportunities
for conflict on the local database and hence you need to write conflict
resolution code that is running persistently (rather than only on
database replication).

I'm hoping that an alternative solution can be found that ensures
consistency on a local node and allows conflict checking to be run as a
process only during database replication.

I *think* we are going to end up using Mr Blakeys patch in the short
term but, hopefully, once I can write up the problem and our analysis
for Damien; an official recommendation might be forthcoming.

Here is my work in progress analysis of the problem

http://www.mail-archive.com/dev@couchdb.apache.org/msg02006.html

Tim


Mime
View raw message