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 >
