D
dbeavon
Guest
@makthar Thanks for the KB articles and the confirmation that you cannot change -Mpb or -Ma on the fly. That is very helpful. I'm discovering that the ODBC connection pooling on windows is managed by the ODBC driver manager itself, and not by the driver/provider. I suspect that there is no way to manipulate the connection pooling behavior from a connection string. Here is a link that explains there are three ways to control ODBC connection pooling, but its not via the connection string, and its not from the ADO.Net API: www.oreilly.com/.../ch01.html *Using the ODBC Data Source Administrator to enable or disable pooling for the entire driver... *Using the ODBC API to control pooling options from an ODBC ... *Editing the registry settings described previously. @ Ruanne Cluer The primary login broker looks like this (can never have too many startup parameters, right?) -B 1500000 -B2 250000 -L 400000 -n 1500 -bibufs 200 -aibufs 200 -lkrela -spin 64000 -S MYPRIMARY -DBService replserv -pica 32768 -tablerangesize 1050 -indexrangesize 4200 -omsize 5200 -semsets 12 -bithold 32768 -lruskips 200 -aiarcdir /aiarchive -aiarcinterval 3600 -prefetchDelay -prefetchPriority 100 -refetchNumRecs 100 -Nmsgwait 2 -Mm 32000 -Mn 62 -Mpb 40 -Ma 5 -Mi 1" Servers By Broker => When I had looked at this, each server was filled to capacity with 40 connections The ODBC clients in question are coming from a front-end user interface application on Windows. The user processes are opening direct connections to the database. I found out afterwards that the connections are in fact being timed-out by the driver manager but not as fast as I would like. In theory the odbc driver manager is supposed to be closing connections after a (default) 60 second connection pool timeout. But in practice it seems to be taking 2 or 3 minutes. (As a side... It is possible that our custom code is part of the problem. The custom ODBC (ADO.Net) code is not releasing connections properly or in a timely fashion. There are some programming patterns in ADO.Net - like "try/finally" or "using" blocks - that are supposed to be used to ensure that connections are closed and disposed, but it doesn't look like the code is rigorously following those patterns. Otherwise I think the driver-manager's pooling behavior would work better.) Since Progress doesn't have a managed .net provider for connecting to the SQL92 engine, I guess I have to become more familiar with OdbcConnection in ADO.Net. It is unfortunate that connection pooling isn't available in the driver itself (except via the ODBC driver-manager). While the OdbcConnection won't support connection strings to manipulate the connection pooling, I did find a method (ReleaseObjectPool - docs.microsoft.com/.../system.data.odbc.odbcconnection.releaseobjectpool ) .. and this may allow us to explicitly close our pooled connections if we need to. Aside from using a method like that, it seems that all .Net applications on the same client machine are impacted by the connection pooling that is provided by the driver-manager.
Continue reading...
Continue reading...