Dispose/Close/Connection pooling - Here is how it all works !!!
Will calling dispose or close have any affect/difference on connection pooling?
Either close, or dispose (by virtue of calling close) would make the connection available for Connectionpooling, provided you haven't disabled connectionpooling otherwise. And yes it is true that Dispose does more than Close - (more on this below).
Definition of "Dispose" ---
Use this method to close or release unmanaged resources such as files, streams, and handles held by an instance of the class that implements this interface. This method is, by convention, used for all tasks associated with freeing resources held by an object, or preparing an object for reuse.
..... All it does is - as stated above - releases resources - which is simply calling close and a bit else as shown below in SqlConnection.Dispose(Boolean) code ---
The extra work other than simply closing that dispose did above was ----- it set _constr to null - which is an instance of an internal sealed class called "SqlConnectionString : DBConnectionString". That class has tonnes of static and const shit in it - it is huge with an ugly vtable - I am sure they must have a reason to do all that, but dude that class is big ugly and expensive - therefore it made logical sense to set it to "null" so GC could merrily come by and swoosh it next time around it's doin' it's thing.
So here is another common question --
Does your datalayer (or any object for that matter) have to implement dispose?
So how does Connection pooling work then? Does Dispose destroy the connection and not release back to the pool (when connection pooling is enabled)?
Dispose - as mentioned above is nothing funkier than calling a method - that does what you saw above. It *does* release and make the connection available for connection pooling. The trick to remember over here is - the actual SqlConnection object is not the object that is pooled - if that were the case, you'd be pooling that yourself through enterprise services or something like that - Microsoft made it easy for you - by implementing an internal sealed class called "SqlConnectionPoolManager", and everytime you call "Open" - and as long as the CONNECTIONSTRING - is *exactly* the same .... connection pooling is automatically taken care of by calling SqlConnectionPoolManager.GetPooledConnection. So all you do is call Connection.Open - and pooling happens AUTOMAGICALLY !! WHOAAAA !! :-)))))
Source: http://dotnetjunkies.com/WebLog/sahilmalik/archive/2004/11/12/31798.aspx
Either close, or dispose (by virtue of calling close) would make the connection available for Connectionpooling, provided you haven't disabled connectionpooling otherwise. And yes it is true that Dispose does more than Close - (more on this below).
Definition of "Dispose" ---
Use this method to close or release unmanaged resources such as files, streams, and handles held by an instance of the class that implements this interface. This method is, by convention, used for all tasks associated with freeing resources held by an object, or preparing an object for reuse.
..... All it does is - as stated above - releases resources - which is simply calling close and a bit else as shown below in SqlConnection.Dispose(Boolean) code ---
The extra work other than simply closing that dispose did above was ----- it set _constr to null - which is an instance of an internal sealed class called "SqlConnectionString : DBConnectionString". That class has tonnes of static and const shit in it - it is huge with an ugly vtable - I am sure they must have a reason to do all that, but dude that class is big ugly and expensive - therefore it made logical sense to set it to "null" so GC could merrily come by and swoosh it next time around it's doin' it's thing.
So here is another common question --
Does your datalayer (or any object for that matter) have to implement dispose?
Just as above - ask yourself this question - "Is my datalayer holding expensive objects?". Remember, dispose is nothing funkier than calling a method, and it is just as good as the Dispose's implementation. Not to mention - it does take some time to call Dispose, and if all you are doing is setting an integer to "0", then it might not make sense to have that extra code/complexity/call/confusion (cccc). What I generally do is this -- http://dotnetjunkies.com/WebLog/sahilmalik/archive/2004/05/19/14019.aspx
So how should I design my data access layer?
a) If you need to pass something - Instead of passing Connection Objects - consider passing connectionstrings and creating connection objects. (For various reasons).
b) Create a ConnectionFactory - similar to ClassFactory - basically you should abstract connection building into one function in the one class - that is the base class of your data access layer. That is a pattern I have used, and I am sure other patterns might exist too.
c) The connection factory function is private to the base class - nobody talks to the connection directly, only via helper functions.
d) No System.Data reference in your business layer.
e) Read chapter #10 of my book for more on this.
a) If you need to pass something - Instead of passing Connection Objects - consider passing connectionstrings and creating connection objects. (For various reasons).
b) Create a ConnectionFactory - similar to ClassFactory - basically you should abstract connection building into one function in the one class - that is the base class of your data access layer. That is a pattern I have used, and I am sure other patterns might exist too.
c) The connection factory function is private to the base class - nobody talks to the connection directly, only via helper functions.
d) No System.Data reference in your business layer.
e) Read chapter #10 of my book for more on this.
So how does Connection pooling work then? Does Dispose destroy the connection and not release back to the pool (when connection pooling is enabled)?
Dispose - as mentioned above is nothing funkier than calling a method - that does what you saw above. It *does* release and make the connection available for connection pooling. The trick to remember over here is - the actual SqlConnection object is not the object that is pooled - if that were the case, you'd be pooling that yourself through enterprise services or something like that - Microsoft made it easy for you - by implementing an internal sealed class called "SqlConnectionPoolManager", and everytime you call "Open" - and as long as the CONNECTIONSTRING - is *exactly* the same .... connection pooling is automatically taken care of by calling SqlConnectionPoolManager.GetPooledConnection. So all you do is call Connection.Open - and pooling happens AUTOMAGICALLY !! WHOAAAA !! :-)))))
Source: http://dotnetjunkies.com/WebLog/sahilmalik/archive/2004/11/12/31798.aspx
浙公网安备 33010602011771号