[asterisk-dev] res/res_odbc.c

[Tilghman Lesher]

On Monday 05 November 2007 07:41, Nick Gorham wrote:
> Tilghman Lesher wrote:
> >On Monday 05 November 2007 03:49:16 Nick Gorham wrote:
> > >
> >http://bugs.digium.com, but since you're already here, I need to ask the
> >obvious question of:  are you using "pooling=yes" in res_odbc.conf?  That
> >option should prevent this issue from occurring.
>
> Yep, I am using "pooling=yes", and no it doesn't seem to stop it happening.
>
> Checking again in the code, I can't see anything that would stop it
> happening with pooling set. The code in handle_cli_odbc_show() locks
> odbc_list, then itterates down the list, calling ast_odbc_sanity_check()
> on each connection. ast_odbc_sanity_check()() then allocates a statement
> and runs its query. I cant see anything in that where there is anything
> that syncronises the query with any other activity on the connection.

Okay, fixed.

> >In terms of the ODBC option, we'll look into it, but I doubt it's as
> > effective as running the generic query.  There are some databases
> > (notably MySQL) where doing the database ping simply doesn't work.
>
> Well, thats entirly up to you (of course), I am not sure just what you
> mean as "effective", its certainly slower than using the method the spec
> suggests as the CONNECTION_DEAD definition does not require (infact its
> not allowed to do ) a client server round trip. Myself I would think it
> would be better to get the driver writers to support the spec, but what
> do I know.

By effective, I mean that it detects all sorts of possible connection issues
that would not otherwise be detected if you don't run a round trip to the
server.  While asking the driver if it thinks the connection is still open
would be a great speed improvement, it doesn't work in the maximum number
of cases (which are sometimes difficult to reproduce and/or diagnose).  When
you have a frustrated system administrator asking why the queries aren't going
through, telling him that he has a driver issue is likely to only add to the
frustration.

-- 
Tilghman