If you ever want to implement the CONDSTORE extension, then it is probably
a good idea to put the effort into atomicity. Basically you will have to
implement write locking mechanisms in your store.
Sure, write locking would be pretty much required in any case. And the store would support atomic updates as well at the cost of more disk space. For message flags this just didn't seem necessary.
The reason that you may want to implement CONDSTORE is if you ever want
someone to use your store in an internet messaging queueing system. If
you are familiar with IBM's MQSeries messaging middleware, then you can
see the advantages of using Internet messaging in interorganization
messaging schemes -- especially with the advent of SOAP over eMail
messaging.
Well, these don't say anything to me really :) But I can see the value of CONDSTORE for synchronizing locally cached metadata more efficiently with server. Especially annotations.
Our experience developing stores very clearly indicates that the sooner you think about threading, sharing and synchronization issues in your design, the better off you will be.
Shared mailboxes are exactly where I was thinking this read-lockless store would work very well. You never have to wait for locks when you're reading the store, and more importantly you never have to wait for readers to finish before you get a write lock. My current design would have one exclusive write lock, which I think is good enough for most uses. More fine grained locking would just slow down normal operations and get too complex. If you want serious simultaneous modifying, you might as well use transactional database as the store.
