On 21/12/2008, at 6:05 PM, Chris Anderson wrote:

I think you are right on about no
synchronous guarantees between updates, and code in external being
run. Marking as dirty is a good way to handle this.

Without some timing guarantee I think even setting dirty is problematic, because it's possible to set a dirty flag from a notification, and yet have a request from the external (e.g. all docs by seq) see a both the dirty flag and pre-notification state, and hence cache old data thinking it's post-notification.

It's the avoidance of this kind of synchonisation problem that makes me think a UUID for the db and a UUID for the generation wrt compaction is a good idea. It reifies state boundaries in a way that can be used by external tools. I don't think there's any other way around it.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.
  -- Douglas Adams


Reply via email to