On Sun, August 12, 2007 14:39, Bart Samwel wrote: > ...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.
But if there's an application running behind the web page, and a query inside that application is taking too long, then at some point the application must conclude that: 1. The user isn't going to get an answer in reasonable time, and it may be better to tell him "no can do" than to keep him waiting. 2. There may be something seriously wrong with the query, or with system load, and the application had better abort the query to protect itself. The user is likely at some point to move on to something else anyway, and it doesn't make much sense to continue processing. Worst case, the user has already tried to reload the page a few times and you may have several instances of the problem query running at the same time. > 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. Yes, if the job can't make its real-time constraint, it should be canceled. If the application consistently can't make its time goals, then it must cope or die. Otherwise you're talking about "fast enough," not realtime. >> 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. That is determined in the back-end, not in the client library: a failed statement aborts the transaction if one was ongoing. >> 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). I'm inclined to agree, but I appreciate the opportunity to discuss it. Any multi-transaction database application should be prepared to catch and handle errors while executing database statements. The cancel is not very different from, say, a resource error or deadlock there. It's also similar in that, if we ignore cancels that don't come during database statements, the exception typically won't show up during testing and exploration. In fact I wonder whether it may make sense to have two versions of cancel: a "cancel current statement" that only aborts a statement if one is ongoing, and a "cancel and die." The latter would guarantee that the ongoing transaction would abort and accept no further statements, regardless of what it was doing at the time. That could be a useful way for a multithreaded application to "reach out and touch" a thread that was doing stuff that's no longer appreciated. The application could implement that as well, of course, but if it means many programmers re-writing the same code, we might as well have it in the library. One problem is, all this asynchronous stuff requires locking. We don't do that right now, and it's a pretty big step to take. Jeroen _______________________________________________ Libpqxx-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
