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.


  • ♿ (Parody)

    @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.


Log in to reply