> Don't allow DB queries that take 30 seconds.  :)
...
> I'm curious about when you have run into this in the past ...

Yeah, I try to avoid it, but sometimes users are adamant, and the old axiom
about "fast, cheap, good, pick any two" bites you in the butt.  30 seconds
is a number I pulled out of the air, and most of the reports for the
tracking system I'm thinking of would actually run much faster, typically in
a second or two, but there were a number which could take in the 5 to 10
second range (already slow enough to cause problems if other users had to
wait on it), and two or three that, if run with worst-case criteria
(encompassing the company's world-wide activities, for an entire year) could
actually take more than a minute.  Most of that time was actually spent
waiting on stored procedures to return results to the web server (separate
machines, both multi-processor, with plenty of RAM).  There just wasn't room
in the budget to set up a proper data warehouse, and the reports were based
on up to the minute results in a transaction-oriented database.

I think I'll plan on going the multi-process route.  Should be simpler to
keep robust, as you wrote, and the only downside (which probably isn't much
of a downside) is that I have to find a good, multi-process friendly session
persistent mechanism.  I think that DirMapping may actually be fine, but I
have a feeling there's a better (higher performance/more scalable) solution
out there.  Perhaps ZODB.

Thanks,

Jason