Connection pool in WinForms app using Data Access Block is exhausting

  • Thread starter Thread starter Jason
  • Start date Start date
J

Jason

I have an application that is using Microsoft's Data Access Application
Block in a WinForms Client/Server configuration. Recently, we have been
having problems where an application is timing out and throwing an error
stating that the connection pool is exhausted, requiring a restart of the
application.

Is there a bug in the Application Block?
 
Hi,

as far as I know not (though I use the older one, v.1.0), but I've seen it
causing those when you make multiple calls to it quickly (for example use
DAAB methods in a loop, and yes we confirmed that no conns were left open)
because it creates temporarily one connection per call, unless you pass it
one as parameter (IIRC it has argument to take the conn too). Of it does the
calls quickly in a loop, it might exhaust the conn pool (because pool cannot
keep up with need of new connections as they are not freed right away on
such loop scenario)

So, the solution has been increasing the pool size for apps which use DAAB
extensively in loops etc. But definately make sure, that you don't leave any
conns open accidentally for example with datareaders (DAAB does create them
with CloseConnection but that yiu close them right away after use). That's
the first one you should check
 
It does appear to be a timing issue. It occurs in high speed data entry
services, label scanning, etc.

Wer're going to try disposing to see if that helps.
 
Nope, I doubt if that will help. Consider that the connection pooling
mechanism creates a new pooled connection if all of the existing connections
are busy or orphaned (were never closed). If you're overwhelming your server
(and it sounds like you are), you have reached the limit of operations/sec
the server can process. I would certainly investigate ways to reduce the
number of round trips or ways to improve the efficiency of the operations
you are requesting. You might be leaving connections open which is typically
the case if you're (or the DAB) is using DataReaders and you're not closing
the connection in scope. Typically, this problem presents itself as a hard
stop--not a transitory problem that comes and goes.

hth

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
This is a shameless plug at the same time but I've written an article which
demonstrates a simple idea how to develop with data readers such that
calling code does not need to take care of releasing resources.

http://aspalliance.com/526

--
Teemu Keiski
MCP, Microsoft MVP (ASP.NET), AspInsiders member
ASP.NET Forum Moderator, AspAlliance Columnist
http://blogs.aspadvice.com/joteke
 
I don't get it. Why is a "shameless plug" to provide help to people? Some of
us have been around long enough and are in a position to help those who need
it. I don't see any shame in that. If you're charging for the article people
have a choice of buying it or not. Some of us make a living providing such
help.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Thanks Bill for the support. :-)

I was just refererring that thread went into giving exact advices, while I
added only my "advertise" to the thread. But yes, the article is free and
should give something to think when developing DALs, so in that sense it is
OK.
 
Back
Top