IDatareader and Database Connections
-
Ok, first, this is a .NET question, specifically VB; I am very tired, and the answer may be obvious.
If I have a Function that returns an IDataReader object to the calling code, and the calling code does not explicitly close the IDataReader, what happens to the database connection?
-
Your connection pool will have one less connection available.
ALSO THE PLANET WILL EXPLODE DEAR GOD NO DON'T DO IT!
No wait just the first one I guess...
-
@blakeyrat said:
Your connection pool will have one less connection available.
ALSO THE PLANET WILL EXPLODE DEAR GOD NO DON'T DO IT!
No wait just the first one I guess...
But what happens when all the connections are used up?
HOW WILL WE EVER GET MORE CONNECTIONS?
-
@blakeyrat said:
Your connection pool will have one less connection available.
ALSO THE PLANET WILL EXPLODE DEAR GOD NO DON'T DO IT!
No wait just the first one I guess...
I thought as much but wanted confirmation from a reliable source in light of the level of "you're wrong" I'm getting from my direct reports.
And, since your statement is in agreement with my thoughts, I will consider you a reliable source in this instance.
-
You are wrong, though. It's just not that huge a deal. But your code is clearly wrong.
-
@Medezark said:
I thought as much but wanted confirmation from a reliable source...
And then you came here?!
-
Not my code, thankfully. I was tracking down an issue where one of our application's active sessions is suddenly growing exponentially. Found a few calls in a very common subroutine that get an open datareader from a function and then never close it.
-
@Medezark said:
Not my code, thankfully. I was tracking down an issue where one of our application's active sessions is suddenly growing exponentially. Found a few calls in a very common subroutine that get an open datareader from a function and then never close it.
That might be it, then - if the data reader went out of scope, but wasn't closed, I'd expect (in a sane world) that it would eventually be garbage collected, but if you're allocating these things willy nilly in a "very common subroutine", that could cause problems, since the garbage collector might not be getting to it in time! (Did I ever tell you about the time I accidentally allocated gigabytes of memory simply by creating byte arrays faster than the .NET GC could clean them up?)
-
@Medezark said:
Not my code, thankfully. I was tracking down an issue where one of our application's active sessions is suddenly growing exponentially. Found a few calls in a very common subroutine that get an open datareader from a function and then never close it.
Yup, you found a bug. Now trade off the cost of fixing it, vs. the cost of setting Max Pool Size = 10000 in the connection string ;)
-
@caffiend said:
Yup, you found a bug. Now trade off the cost of fixing it, vs. the cost of setting Max Pool Size = 10000 in the connection string ;)I don't think that would help, as our oracle instance is apparently running on a TRS-80 Model I with a tape drive, or something equally underpowered.