none
odbcconnection hangs on .Open() under heavy load RRS feed

  • Question

  •  

    Hi,

     

    I am developing a webservice which retrieves data via an 3rd party ODBC driver and returns as a serialized byte array. The system runs fine under a light load when requests are spread apart. However, when I introduce some load the calls from the client hang. This is using the standard .net 2.0 odbcconnection classes. Debugging w3wp.exe processes reveal the code is hung on:

     

    myConn.Open();

     

    It would appear that opening many connections at once seems to hang the thread in the worker process. I always close and dispose my connection objects in a finally block at the end of the method, so there is no issue there. Sometimes the thread will hang on the .Close() mthod of the connection.

     

    I thought this may be a threading issue, so i surrounded the .Open() and .Close methods with:

     

    lock(myConn)

    {

    myConn.Open();

    }

     

     

     and that does seem to have helped an allowed me to increase the stress on the server slightly more, however, under heavy load, I still find the code hung on the .Open(0 methods and sometimes on the .Close() as well.

     

    Increasing the worker processes in the web garden does appear to improve things although not as much as I'd like and i'm concerned about throughput.

     

    Any help would be appreciated. At the moment, I am thinking of implementing some form of open request queue which will allow me to limit the number of open connections at one time?!

     

    Please help!!!!

     

    Thanks,

     

    Matt.

    Thursday, October 18, 2007 3:29 PM

All replies

  • I would check to see if the company that produces the provider has any input on this.  Does this odbc provider have any support for connection pooling?  You might also try creating an Enterprise Serviced (COM+) wrapper for the odbc provider, placing it in COM+ Services.  If you do this you can pool the wrapper using COM+ services and preload instances of the wrapper in your COM+ application context.

     

    -David Sandor

     

    Thursday, October 18, 2007 4:14 PM