I realize that this is very specific to the database, however, it may be
possible to set a resource limit at the database level that will prevent
the queries from consuming too much time.
Chuck
[EMAIL PROTECTED] wrote:
On Sep 18, 2006, at 6:18 PM, Tyler MacDonald wrote:
Dean Arnold <[EMAIL PROTECTED]> wrote:
Which brings me back to the notion of non-blocking requests.
Assuming
many/most client libs do support an async capability, and a OOB
cancel, then it should be possible to standardize the behavior
externally.
Attempting to standardize, let alone implement, non-blocking requests
for the current DBI is a far bigger task than the above.
On the other hand, I'd be *delighted* if you, or anyone else, would
like
to champion the work.
<cheap hack>
Start up a thread to handle the request, which sets a state
variable on
the statement handle then the request has been processed?
</cheap hack>
The problem is not to know when a request is done processing.
The problem is killing requests that are processing for too long.
If you want kill them safely, you may not be able to kill them until
they're done, which defeats the purpose.
If you kill them "unsafely", then the Perl interpreter might be in a
dirty state, forcing you to thoroughly dispose of it if you want to be
100% safe.
To kill the requests safely and when you want to, you need
asynchronous support from the database client APIs and drivers, and
quite a bit of standardized support code from DBI.
H
