On 12 Oct 2012, at 10:01pm, Nico Williams <n...@cryptonector.com> wrote:
> On Fri, Oct 12, 2012 at 3:53 PM, Simon Slavin <slav...@bigfraud.org> wrote: >> That's an interesting idea. I have a question. Suppose your program >> received the 'success' result for a transaction and carried on to do other >> transactions. Later you test to see whether the transaction is durable and >> find that it isn't. What would be a useful thing to do at that point ? > > It depends. For most such applications I'd say this is just not > appropriate. But you might have an application where this is fine, > provided you have a way to reflect the D/not-D state of the initial > transaction in the dependent ones. To do that properly, you would need a multi-value variable. Because for every operation you actually have three statuses: 1) Operation hasn't been started yet. 2) Operation is just about to start ... here the computer actually tries to do the operation 3a) Operation complete and failed 3b) Operation complete and succeeded The problem with your process as stated is that the operation may be complete (correctly written to disk and therefore durable) but the software may not yet have set the flag to indicate that. If your software looks at the status and sees 'not durable' it might take 'not durable' actions on something which is actually durable. > What I had in mind was something more like a booking system: let the > user know that the transaction completed by updating the page so as to > make the form go away, but leave an indicator (e.g., animated > ellipsis) to indicate that the transaction is not quite completed. 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. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
