On Fri, Oct 12, 2012 at 4:08 PM, Simon Slavin <slav...@bigfraud.org> wrote: > If all you're doing is showing something on a display that's fine. But if > that's what you're doing I see no point in distinguishing between 'success' > and 'durable'. As far as I can see your program has nothing to do between > the two statuses.
D.R. Hipp asks for a write barrier so that ACI (no D) can be implemented easily. It turns out that this is possible (as described earlier). I also suggest that "delayed D" might be of use. I don't have great examples where one might want delayed D, but still, I would rather have an API for learning when D is achieved. You propose not having such an API at all (or at least imply it). Why wait for someone to ask for what is clearly a sensible API to have? Sometimes the existence of an API can foster development of consumers. Sometimes an API w/o initial consumers dies on the vine. It's a matter of judgement whether to add an API before having definite consumers, but IMO it's worth doing in this case. Here's some more examples of where delayed-D ACKs would be nice: distributed services. These are really just a variant of my earlier UI example, but still: a server might respond with an ACK as soon as a transaction completes with ACI and again when D is achieved, thus allowing different clients to choose when to demand D independently of each other. A logging system might want ACID for critical messages and ACI for for all others. Durability is generally required in production systems. So good examples where it's not necessary are hard to come by. Yet another variant on my first example would be a mobile note taking app that uses color (or an icon) to indicate when the current state of the document is safely committed on disk (flash, really). The mobile device environment generally requires D but doesn't require D before proceeding. Perhaps this is the best example I have so far. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
