Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of antony.blakey@gmail.com
 designates 209.85.142.191 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=dRZXLe0IkPqY4C5cfuSYiJMwnJU6z4qCtNA4APOxLys3fRBbCsSLz7jVNZkbKg/qG3
         CCNViy5/cyqtsvEhe+f4sIwItRsHbwJWFAPomXONb3BQbDS3+5Kwf5Iz6kWyLP8gneFn
         wF0vxcxdyZO/EQi81PRbNThSmdtKgdOqx4PsA=
Message-Id: <CB9BE9A0-D888-4E89-9AD4-0494D91E9427@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: user@couchdb.apache.org
In-Reply-To: <49D7206D.7010907@gmx.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.4)
Subject: Re: how to ensure transactions over multiple documents?
Date: Sat, 4 Apr 2009 20:34:17 +1030
References: <bf83b4ef0904020449j23827c4fl746aed435f6b6ab@mail.gmail.com>
 <49D60586.7090108@timparkin.co.uk> <49D61871.1090608@proven-corporation.com>
 <bf83b4ef0904030717h3ea7bad6o3f8fa148543c0b4d@mail.gmail.com>
 <49D61D2B.7090600@proven-corporation.com> <49D62252.1050007@timparkin.co.uk>
 <49D62402.2010904@proven-corporation.com>
 <bf83b4ef0904030822g563d9a8sde3c371ec47c67f8@mail.gmail.com>
 <EFD9017A-C722-4890-83E6-14114B9A3D49@gmail.com> <49D7206D.7010907@gmx.de>


On 04/04/2009, at 7:25 PM, Sven Helmberger wrote:

>>> 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.

I'm going to bet that it's not possible, if for no other reason than  
the lack of a low level interposition mechanism that covers updates  
generated by replication.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Reflecting on W.H. Auden's contemplation of 'necessary murders' in the  
Spanish Civil War, George Orwell wrote that such amorality was only  
really possible, 'if you are the kind of person who is always  
somewhere else when the trigger is pulled'.
   -- John Birmingham, "Appeasing Jakarta"