Women in Technology

Article:		ADO.NET Connection Pooling Explained
Subject:		Slightly bad advice
Date:		2004-02-25 08:00:49
From:		asills
While the technique provided here is definitely valid, one huge thing you missed is I would probably bet that a lot of novice web developers will take this code as is and use it in their web applications, without realizing the multi-threaded problems that might arise when using this code. Since ASP.NET is a multi-threaded environment, multiple threads could be failing and accessing the static variable at the same time, causing the retries variable to change from multiple threads, which would cause its value to be changed by one thread while another thread is dependent on the value being a certain thing. So just FYI, be wary if you use this code, that it's not thread-safe.

Showing messages 1 through 1 of 1.

• Slightly bad advice
  2004-04-15 22:58:50  AndrewG [View]
  
  
  A bit more information
  You're right in saying ASP.NET is multi-threaded, but each request comes in on it's own thread and is seviced by a unique application instance. This means you don't have to concern yourself with MT issues - simply because all variables are local to your application instance. ASP.NET application objects are pooled and removed/returned to the pool upon each request/reply.
  Shared/static variables will require protection from concurrent access. This is due to shared/static variables being maintained at the AppDomain level and not the Application level.
  In the example of connection pooling a simple non-shared/static variable in the application object (initialized with the pool count) would be sufficient