I was just curious if anyone has dealt with the issue of pooled connections when trying to create a database access layer.
I'm working on a project that was given to me and I've been running into issues with the connection pool of 300 being maxed out. After finding some of my own mistakes I've found that the data layer created by the original designers has a connection leak that they apparently chose to ignore. Some of the objects have a findall method that goes something like this
Public Function FindAll() As SqlDataReader
Dim found As Boolean = False
Dim conn As SqlConnection = New SqlConnection(_DSN)
Dim myCommand As SqlCommand
Dim myReader As SqlDataReader
conn.Open()
myCommand = New SqlCommand("sproc_tbNetwor
myCommand.CommandType = CommandType.StoredProcedur
myReader = myCommand.ExecuteReader()
Return myReader
End Function
Obviously they couldn't close the connection because then the reader wouldn't work so they just left it like this. Since they let the connection object go out of scope it'll sit in the pool until GC picks it up which I've heard can take hours.
Has anyone else dealt with this in an elegant fashion? I'll give points to anyone who provides some useful information.
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
I suppose that's one solution though I was hoping for something a bit more transparent.
To remedy the current situation I simply threw the connection into an instance object and then made a sub called close that closes the instance object if it's not null.
It works well for this kind of situation but I can imagine situations where even this might get hairy.
ExecuteReader can take a "commandbehavior" parameter that can close the underlying connection when the datareader is closed.
Change like this:
myReader = myCommand.ExecuteReader(Co
This ExecuteReader override is documented here.
http://msdn2.microsoft.com
Another route is to use a class for your dataaccess, and implement IDisposable. Declare your connection object at the module level, and Dispose of it in your classes Dispose method. Then any method calling the FindAll method of your class would also be responsible for calling Dispose (or use the Using keyword when creating your dataaccess class.)
Business Accounts
Answer for Membership
by: naspinskiPosted on 2008-04-26 at 23:02:34ID: 21448305
Can you try passing the connection as well? Then after the reader is consumed, close it in another function?
Just thinking out loud here:
Make this function a void, and at the end, call doSomeStuff(SqlDataReader myReader, SqlConnection conn)
And in doSomeStuff, call whatever is working with the datareader, and hold until its done, then close the connection?
I suppose this could all be done within the function as well, but that coudl get messy.
Do you understand what I am saying?