couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven Helmberger <sven.helmber...@gmx.de>
Subject Re: how to ensure transactions over multiple documents?
Date Sat, 04 Apr 2009 08:55:09 GMT
>> Spring allows you to create application-wide singletons, one of which
>> could be the jcouchdb Database object.
>>
>> In order to keep the write serialization more or less transparent to
>> the application developer, I guess
>> 1) I'd write an aspect on top of that bean, that would proxy the
>> update/delete related operations, adding the identity of object
>> operated on to an active object list (exact data structure might
>> vary).
>> 2) Another aspect would handle the bulk insert method; it would check
>> if any of the objects being inserted/updated are already in the active
>> objects list, and if not, add all the inserted object ids to the
>> active object list before update, and removing them afterwards.
>> 3) Operations (update/delete) that affect objects already in active
>> object list would simply throw an exception without even hitting
>> couchdb.
>>
>> Then just serialize the access to that active object list. What do you 
>> think?
> 
> You would still get conflict on update unless you serialise all access 
> and check the existing rev of all intended updates before committing. 
> I'm not sure the active list buys you much - you also need to deal with 
> replication updating the db.
> 

I wonder if there's really a way to handle this in any transparent way 
(with or without Spring/AOP).

To me it seems like a explicit working set you can add stuff to and that 
you can finally commit would be most helpful. I'm not sure how such a 
thing should work. You can sure add all kinds of documents to the 
working set and use bulk update to commit it, but what do you do when 
some of the documents conflict? Trying to restore the conflicting 
documents' previous revision seems like the best bet, but even that 
seems like it can't really work in all cases.

Regards,
Sven Helmberger

Mime
View raw message