Admin configuration for database query/transaction timeouts

Here's the scenario:

A user submitted a request from a Confluence page (containing a macro), which is submitted from the browser to Tomcat via HTTP. The requests (HTTP Connector) timed out after 2 minutes and Tomcat returns a 503 error to the browser. The database query however will still be executed.

A customer pointed out that the ability to cancel a request that takes unexpectedly long to complete - usually due to an error in page code - should be available to a page author or viewer.

A quote from the customer:

Many is the time I have previewed a reporting macro invocation that I didn't want to complete, or tried to troubleshoot a user's problem and been stymied because editing the page required me to view it first, and the 503 message didn't allow the page to render so that I could click its edit link. I know, of course, that I could look up its content ID and invoke the editpage action independently, but that's time-consuming and irritating.

And, of course, 503 (service unavailable) is not what I would think of as an appropriate response to something that was taking too long to complete, though of course there may not be any other conclusion the respondant server could reach under the circumstances.

But in the final analysis I still can't imagine a case where a transaction - at least, one whose only purpose is to provide a response with no persistent side effect - should be allowed to continue after it is known for certain that the requestor will never receive that response. This is especially important when the user's most likely action in the face of such a situation is to try it again - often multiple times - raising the probability of deadlocks, delays and wasted resources that can build to performance-affecting - and even service-threatening - levels to near certainty.

Even for an action that does have persistent side effects, I would not find it acceptable to be uncertain of whether they had been executed under such conditions. If there is a meaningful risk that it may take unreasonably long to complete, it would be more sensible to use job scheduling to put it explicitly into the background, with the ability to monitor its state.

An interface that indicates running queries or actions might also be helpful in this case.