Michael Peppler
Sybase Consulting
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
Sybase on Linux FAQ
Sybperl FAQ
Michael Peppler's resume

sybperl-l Archive

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, wrote:
> Quoting Michael Peppler :
> > On Fri, 2003-01-03 at 08:34, 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

> 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 -