EntLib wont work with ConnectionPooling

Topics: Data Access Application Block
Mar 8, 2010 at 6:49 AM
Edited Mar 8, 2010 at 10:15 AM

Hi all,

With my previous experience of EntLib, I've learned that we as a programer can't take advantage of Connection Pooling support by databases.

What is your take on this concept? This question is targetting for the core team as well as the folks that are using DataBlock.

Thanks for reading,

Chakravarthy

Mar 8, 2010 at 7:42 AM

How did you come up with that conclusion?  If you used connection pooling, closing an ADO.NET connection will be returned to the pool regardless if you used any wrapper or even DAAB.

 

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

Mar 8, 2010 at 12:00 PM

Hi,

Thanks for the reply. If you see the code written for ExecuteReader, it is not closing the connection that it is using. Thus, every time you create an instance for this method, you get a new connection. Correct me if am mistaken.

Mar 9, 2010 at 5:00 AM

Hi,

Yes, the ExecuteReader method does not close the connection. However it is documented why it does not close the connection. You can find it here http://msdn.microsoft.com/en-us/library/dd203181.aspx . It is the application that will be responsible for closing the reader.

Valiant Dudan
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

Mar 9, 2010 at 6:12 PM

The connection has to stay open in order for you to actually use the reader to read data. When you close the reader, the underlying connection will be closed, unless you're inside a transaction, where you don't close the connection until you're done with the transaction.

 

Mar 10, 2010 at 1:39 PM

In general, the developers would not give attention and we as the project leads have to be constantly behind the developer to question that they have written the code to close the connections where ever they have used the ExecuteReader method.

This is the point that am trying to mention. Secondly, when ever a new connection is required by the another thread, that thread doesn't use the connection which is already opened. Thus, resulting many connections open during the project execution. Imagine a situation where you have millions of users connected to the web app with such open connections!!!!???

I've came out with a wrapper for this kind of situation and wanted the EntLib Team should think about this issue