[unixODBC-support] Connections not being re-used with pooling enabled?

Kris Powell kris.powell at gmail.com
Wed Dec 28 10:03:41 GMT 2016

Hi folks

I'm hoping you can help me understand a problem I'm having with unixodbc connection pooling. (I'm using unixodbc with freetds sitting under a python django app running under apache with pyodbc/ django-pyodbc-azure.)

I've enable pooling with the following settings:

Trace = no
TraceFile = /tmp/odbc.log
Pooling = Yes

[SQL Server]
Description = FreeTDS driver for SQL Server
Driver = /usr/lib/i386-linux-gnu/odbc/libtdsodbc.so
Setup = /usr/lib/i386-linux-gnu/odbc/libtdsS.so
CPTimeout                   = 1000
CPTimeToLive        = 100
CPProbe             = SELECT USER
FileUsage                   = 1
DontDLCLose                 = 1

If I have Pooling = No, then as expected a new connection is established to the SQL Server with each request. After the request is complete, in netstat I see a bunch of connections to the sql server go from ESTABLISHED to TIME_WAIT and then close. Each new request establishes new connections which are then closed at the end of the request.

But if I set Pooling = Yes, I see new connections being established with each request, and stay on ESTABLISHED. When I issue a second request, I see a bunch new connections being set up, which also stay established. This continues until I have several dozen connections established, at which point I restart apache to clear them.

I would have expected the prior established connections to start being re-used by subsequent requests.

I'm using unixodbc 2.2.14 and freetds 0.91-1 / 0.91-5 (default packages on ubuntu 12.04 and 14.04, respectively.)

I've spent the morning googling, reading and poking around the source but am not much wiser. Any pointers/ ideas? Under what circumstances would I expect the connections to be re-used? Has anyone seen behaviour like this? I'm I doing something fundamentally wrong/ dumb? Am I poking around the wrong layer maybe? Do I need to be down in freetds?

Any help much appreciated!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-support/attachments/20161228/728a9781/attachment.html>

More information about the unixODBC-support mailing list