Up Prev Next
From: Michael Peppler <mpeppler at peppler dot org>
Subject: Re: Timeouts
Date: Jan 3 2003 6:25PM
On Fri, 2003-01-03 at 10:09, email@example.com wrote:
> Quoting Michael Peppler :
> > On Fri, 2003-01-03 at 08:34, Matthew.Persico@Lazard.com wrote:
> > > Is there a way, with DBD::Sybase, on a statement handle level, to either
> > detect
> > > a lock or set a timeout on a statement execution?
> > See the "timeout" connection property.
> > However I realize now that this should really be a database handle
> > attribute, settable as needed (right now you can only set this at
> > DBI->connect() time, unfortunately).
> Before we go off and start patching, consider the following...
> Here is the underlying CTLib doc on timeouts:
> In particular:
> "ct_config can be called to set the timeout value before or after a call to
> ct_connect creates an open connection. It takes effect for all open connections
> immediately upon being called."
Ah - I was wondering why I did it this way... The timeout property is
set for the context (CS_CONTEXT), not for the connection as such. As all
connections share a context, setting the timeout property in DBD::Sybase
will affect all open connections, and any connections opened later on.
I've used timeouts with good success at eCircles in a pooled connection
setup for a web application. I set the timeout at 30 seconds, figuring
that anything that took more than 30 seconds to complete was dead
> Is this the way it works now at the dbhandle level? Does the timeout get
> applied to all currently open handles? Subsequently opened handles?
> If we were to implement this on a statement handle level, the programmer would
> have to
> 1) Set the appropriate $sth attribute with a function call. The call would have
> to return the current value, which the programmer would have to store.
> 2) $sth->prepare, execute or $sth->do.
> 3) Reset the attribute to the original stored value.
> 4) $sth-fetch to process rows.
We might be able to use perl's "local" operator, but apart from that the
above looks correct.
> Otherwise, all subsequent executions on ANY open database handle would be
> subject to the timeout.
> Seems to me that this pretty much rules out using this in a multi-threaded
> program OR a pooled connection environment.
I see what you mean - if you want to place a very short timeout on
something then it may cause problems for other apps in the same process.
Using separate contexts would be possible, however. Though that may
imply a fair amount of work in DBD::Sybase...
Michael Peppler Data Migrations, Inc.
Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or
long term contract positions - http://www.mbay.net/~mpeppler/resume.html