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.
Regards,
Sven Helmberger
