Hi Jeroen, Let me add my EUR 0.02. There are two typical use cases for a "cancel", I guess:
1. User interaction (the user cancels processes that take too long). 2. "Real time" (the answer doesn't matter anymore after some deadline has passed). Jeroen T. Vermeulen wrote: > 3. As a timeout option for connection_base::exec()! It may invite more > cancellations than is really healthy, but it'd be a very user-friendly way > to support realtime-ish behaviour. User interaction, for instance, is a > very common realtime task. ...but generally intended to be a precise one if the user doesn't manually cancel what he's waiting for. So timeouts are generally not the thing. Think of loading web pages: there's a network timeout of several minutes, but there's also a "stop" button. I would be very annoyed if I would replace this with only a timeout, but not with only a stop button. And consider "real-time monitoring" software, e.g. something displaying a graph. If the data doesn't get there on time for a once-a-second graph update, should the query be cancelled? No: otherwise it probably won't get there on time *every* second. Instead, the software lowers its update frequency to what the database can provide. However, the query should be canceled when the user tries to exit the application. :-) That is to say, I like the option of a timeout, and I think it may be very useful for non-interactive tasks, but I think for interactive use the "interactive cancel" is more common. > And of course there's the matter of transactions. Do you abort the > transaction (if any)? Treat it the same as a statement failure. I don't know how pqxx behaves in this respect: if statement failure only rolls back the statement itself, then it should do that. If statement failure aborts an entire transaction, then it should do that. > What if you're not currently executing any queries > so that the cancel is a no-op from the database's perspective? Do you > abort, throw, ignore? I can give you a definite answer to that one. You ignore. Quite simply put: as a programmer you can never make sure that the database is busy and then cancel in the safe knowledge that the database will not *just* have finished what it was doing. So if you throw/abort, you basically force all users of cancel() to try/catch around it. Worse: if they only cancel long-running queries, they may not ever find out you're throwing on this condition until production time (because they didn't encounter the race condition in testing, it being unlikely when long queries are involved). Cheers, Bart _______________________________________________ Libpqxx-general mailing list Libpqxx-general@gborg.postgresql.org http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
