sybperl-l Archive

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, persicom@acedsl.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?
> 
> [snip]
> 
> > 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:
> http://nycux-tch102:8090/dynaweb/cng1110e/ctref/@ebt-link;pt=13116?target=%25N%
> 15_16792_START_RESTART_N%25
> 
> 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
anyway...

> 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
-- 
Michael Peppler                              Data Migrations, Inc.
mpeppler@peppler.org                 http://www.mbay.net/~mpeppler
Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or 
long term contract positions - http://www.mbay.net/~mpeppler/resume.html