couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrius Juozapaitis <andri...@gmail.com>
Subject Re: how to ensure transactions over multiple documents?
Date Fri, 03 Apr 2009 15:22:46 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?

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.  I'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 + jcouchdb
>>>> + 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.  If
> I absolutely had to have transactions implemented on CouchDB then I would
> probably begin by learning about well-known locking, transaction, and
> logging designs from a good book or other source.  If I absolutely couldn'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 implement
> my project on top of Berkeley DB directly and just use its API for all of
> those features.
>
> --
> Jason Smith
> Proven Corporation
> Bangkok, Thailand
> http://www.proven-corporation.com
>

Mime
View raw message