Raymond O'Donnell wrote:
>
> Hello all,
>
> I've been having a lot of trouble with connections sitting around
> idle for a long time after a query has executed. I'm building a web
> app which uses ADO on a windows computer to talk to the ODBC driver
> (version 7.02.0004, installed with pgAdmin II), which then talks to
> PostgreSQL on a Linux machine.
>
> I've been looking at the psqlodbc-xxxxx.log and basically, what is
> happening is that the query is executed as normal, then nothing
> happens for about 80 seconds (during which I can see the idle backend
>
> process on the linux server), and then suddenly the command
> "PGAPI_Disconnect" appears in the log and the backend finally
> terminates.
>
> I've tried this (i) calling the ADO objects from an ASP script (see
> [1] below) and (ii) calling the ADO objects from a COM DLL created in
>
> Delphi (pretty much the same as in the ASP script) to be called from
> an ASP script. In both cases, the backend hung around for about 80s,
> even though the connection has been explicitly closed and the
> connection object removed from memory. I've appended a typical set of
>
> log entries at [2] below.
>
> Interestingly, creating another Delphi app that talks to Postgres via
>
> either the Zeos components (which don't use either ADO or ODBC)
> causes the backed to die immediately once the connection is closed.
> This seems to imply to me that either ADO or the ODBC driver itself
> is for some reason keeping the connection open rather than closing it
> immediately.
Yes IIS uses the connection pooling mechanism by default.
Pooled connections would be re-used if possible for other
sessions without re-establishing new connections.
Anyway I can't see other sessions' info at all in your
example. How do other sessions behave ?
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
