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
, dbi-dev
Subject:Re: Safely timing out DBI queries
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
On Tue, 19 Sep 2006 [EMAIL PROTECTED] wrote:
And some drivers have a timeout parameter that handles this issue at the
vendor API level (e.g. DBD::Sybase's timeout parameter that is handled
internally by OpenClient).
Good to know. I'm looking into adding something like this to MySQL,
but
On Sun, Sep 17, 2006 at 10:59:48AM -0700, Dean Arnold wrote:
(I've added dbi-dev as this seems relevant)
Tim Bunce wrote:
On Sat, Sep 16, 2006 at 08:31:54PM -0400, Sam Tregar wrote:
On Sat, 16 Sep 2006, Dean Arnold wrote:
I think your best bet might be to work with the DBD::mysql
Tim Bunce 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
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
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
Henri Asseily [EMAIL PROTECTED] wrote:
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
On Sat, Sep 16, 2006 at 08:31:54PM -0400, Sam Tregar wrote:
On Sat, 16 Sep 2006, Dean Arnold wrote:
I think your best bet might be to work with the DBD::mysql maintainers
to implement some driver-specific nonblocking versions of
execute/prepare (and maybe fetch), as well as support for
'out
Also, rather than fork each time you need a timeout it would be
nice to
be able to have a single 'watchdog' process and use some form of fast
IPC to tell it when to be active (passing the timeout to use and
relevant session id) and when to be inactive. A pipe would be fine.
But perhaps that
unsubscribe immediately
*
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed. If you have received this email message in
Read The Fine Mail headers which tell you how to do so!
On 17.09.2006 13:47, Martin Gainty wrote:
unsubscribe immediately
*
This email message and any files transmitted with it contain confidential
information intended only
, 2006 8:31 AM
Subject: Re: Safely timing out DBI queries
Read The Fine Mail headers which tell you how to do so!
On 17.09.2006 13:47, Martin Gainty wrote:
unsubscribe immediately
*
This email message and any files transmitted
-users dbi-users@perl.org
Sent: Sunday, September 17, 2006 8:31 AM
Subject: Re: Safely timing out DBI queries
Read The Fine Mail headers which tell you how to do so!
On 17.09.2006 13:47, Martin Gainty wrote:
unsubscribe immediately
On Sun, 17 Sep 2006, Tim Bunce wrote:
For any driver that uses a network socket to connect you could close()
the socket in the signal handler to (relatively) safely timeout.
Should be fairly clean/safe for the db client library state, though
unsafe signals means there's still a chance perl's
On Sun, 17 Sep 2006, Henri Asseily wrote:
This is a good way for handling a few potentially long-running queries, but
forking each time means that you create a new dbh each time, correct? That's
impossibly slow for environments like high-volume webservers.
Right. And a few long-running
(I've added dbi-dev as this seems relevant)
Tim Bunce wrote:
On Sat, Sep 16, 2006 at 08:31:54PM -0400, Sam Tregar wrote:
On Sat, 16 Sep 2006, Dean Arnold wrote:
I think your best bet might be to work with the DBD::mysql maintainers
to implement some driver-specific nonblocking versions of
On Sun, 17 Sep 2006, Dean Arnold wrote:
Er, but how ? Unless/until the DBI is threadsafe, the only way
for kill_session() to work is by breaking the DBD out of the
current blocking request. Which I assume is to be accomplished
by throwing signals around ?
DBIx::Timeout uses a separate
On Sun, 17 Sep 2006 10:59:48 -0700, Dean Arnold wrote:
Hi Dean
just swallow the signal. (I'll note that signals are conclusive
proof that UNIX
was developed in an era when recreational narcotics were readily
available and inexpensive.)
The more things change, the more things stay the
3:15 PM
To: dbi-users@perl.org
Subject: Safely timing out DBI queries
Greetings all. I'm working on an app which allows users to construct
queries using a web UI in a moderately free-form fashion. There's
plenty of data and hence plenty of rope. I need to save my users from
themselves
On Sat, 16 Sep 2006, Henri Asseily wrote:
Use the great Sys::SigAction by Lincoln Baxter.
That's just a wrapper around POSIX sigaction(), right? As I
understand it that's equivalent to the old unsafe signals in Perl
before 5.8. I'd rather avoid that if it all possible!
-sam
On Sep 16, 2006, at 8:58 PM, Sam Tregar wrote:
On Sat, 16 Sep 2006, Henri Asseily wrote:
Use the great Sys::SigAction by Lincoln Baxter.
That's just a wrapper around POSIX sigaction(), right? As I
understand it that's equivalent to the old unsafe signals in Perl
before 5.8. I'd rather
On Sep 17, 2006, at 12:05 AM, Henri Asseily wrote:
On Sep 16, 2006, at 8:58 PM, Sam Tregar wrote:
On Sat, 16 Sep 2006, Henri Asseily wrote:
Use the great Sys::SigAction by Lincoln Baxter.
That's just a wrapper around POSIX sigaction(), right? As I
understand it that's equivalent to the
On Sun, 17 Sep 2006, Henri Asseily wrote:
You've got a catch-22: If you ALWAYS want the signal to fire on time, then
you should expect unsafe signals.
Just clean up after yourself.
It's hard to clean up after the kind of problems unsafe signals can
cause. For example, imagine the DB client
I'm not really qualified to comment on DBD::mysql, but...
I just saw your note on mysql internals, and suspect your
request there is unlikely to be given serious consideration.
I think your best bet might be to work with the DBD::mysql maintainers
to implement some driver-specific nonblocking
On Sat, 16 Sep 2006, Dean Arnold wrote:
I just saw your note on mysql internals, and suspect your
request there is unlikely to be given serious consideration.
Always a possibility. Maybe they'd be more interested in a patch.
(For the curious, I wrote a message to the MySQL internals
Greetings all. I'm working on an app which allows users to construct
queries using a web UI in a moderately free-form fashion. There's
plenty of data and hence plenty of rope. I need to save my users from
themselves by timing-out long-running queries and killing the MySQL
thread.
Our first
nameless.
-Original Message-
From: Sam Tregar [mailto:[EMAIL PROTECTED]
Sent: Friday, September 15, 2006 3:15 PM
To: dbi-users@perl.org
Subject: Safely timing out DBI queries
Greetings all. I'm working on an app which allows users to construct
queries using a web UI in a moderately free-form
28 matches
Mail list logo
