If request timeout is a configuration file parameter, all databases on a
given system will have to share the timeout limit. This means that it
will have to be set above the elapsed time for gbak to backup the large
table in any database on the system or forgo backups. On the other
hand, it is highly unlikely that the worst case gbak backup request will
be satisfactory for catching runaway requests or accomodating bored
users. If we are going to go to a configuration based timeout, is it
reasonable to ask system manages to shut down, change the configuration,
and restart the servers before and after they want to do backups?

If, on the other hand, the timeout is attachment or request based, the
application programmers will have to take explicit action to set a
timer. And, if they're going to have to modify their programs to take
advantage of a server timeout, doesn't it make more sense to ask them
make equivalent changes to invoke a client side timeout?

The feature request that sparked this thread was looking for a solution
to catch runaway requests from bad programmers. Perhaps other people
have different experiences, but while I have known many bad programmers,
I have never met a bad programmer who didn't think he was an
exceptionally clever programmer. So I have to wonder whether a feature
designed only for bad programmers will ever get used.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376