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 <[email protected]> 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? > > 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 <[email protected]> > 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 >> >
