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 awolff@gmail.com designates
 209.85.221.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=BqBj/czN4BARiOGJaFKjmshs6qADLJuzbtCTOacs1cbcvjKpSCujpO+EnHDZQ6LOOy
         F0eiW2c2CDYPhC1GvYkpxc447qHgc1Rq5Jy/dXC3OO9faqTzk6jZoBw97T0EoZr6+Ewd
         lBzZGwxeHRC4F4moBQjxSRwH9QDJP8MP+wndM=
MIME-Version: 1.0
In-Reply-To: <bf83b4ef0904030822g563d9a8sde3c371ec47c67f8@mail.gmail.com>
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>
Date: Fri, 3 Apr 2009 09:06:16 -0700
Message-ID: <e8d26ac40904030906j666a3a0cw6fef6c355d1d42e9@mail.gmail.com>
Subject: Re: how to ensure transactions over multiple documents?
From: Adam Wolff <awolff@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I've been looking at something similar to this. You could make this
pretty elaborate -- using Rhino, you could even run views against the
cache. Makes sense to me.

A

On Fri, Apr 3, 2009 at 8:22 AM, Andrius Juozapaitis <andriusj@gmail.com> wr=
ote:
> 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 th=
ink?
>
> That's just the idea, not an actual implementation, so please bear
> with me on this one ;)
>
> regards,
> Andrius Juozapaitis
>
>
> On Fri, Apr 3, 2009 at 5:58 PM, Jason Smith <jhs@proven-corporation.com> =
wrote:
>> Tim Parkin wrote:
>>>
>>> Jason Smith wrote:
>>>>
>>>> Hi, Andrius. =A0I'm not familiar enough with Spring but yes, perhaps a
>>>> synchronization mechanism would work there.
>>>>
>>>> Andrius Juozapaitis wrote:
>>>>>
>>>>> Hey Jason,
>>>>>
>>>>> I can't seem to get my head around this. I use gwt + spring + jcouchd=
b
>>>>> + couchdb. I'd guess that you're suggesting serializing writes to
>>>>> couchdb in spring layer, using some kind of synchronization mechanism=
?
>>>>>
>>>>> regards,
>>>>> Andrius
>>>
>>> Hi Jason..
>>>
>>> I'm not familiar with your use of synchronisation here. Could you
>>> outline how you would ensure multi update integrity using
>>> syncronisation? I'll add it to my documentation for the bulk update
>>> integrity stuff..
>>
>> I'm not sure, as I have always relied on ACID-compliant relational DBs. =
=A0If
>> I absolutely had to have transactions implemented on CouchDB then I woul=
d
>> probably begin by learning about well-known locking, transaction, and
>> logging designs from a good book or other source. =A0If I absolutely cou=
ldn't
>> re-engineer to have all transactions occur at the document level of
>> CouchDB--in other words, if I absolutely had to have a locking,
>> transactional, replicating key/value store, then I would probably implem=
ent
>> my project on top of Berkeley DB directly and just use its API for all o=
f
>> those features.
>>
>> --
>> Jason Smith
>> Proven Corporation
>> Bangkok, Thailand
>> http://www.proven-corporation.com
>>
>