Scott Hanselman

A tale of two techniques: The [ThreadStatic] Attribute and System.Web.HttpContext.Current.Items

May 23, '03 Comments [10] Posted in Web Services | ASP.NET
Sponsored By

Today's lesson learned: the [ThreadStatic] attribute is only useful when YOU control the ThreadPool (and the lifecycle of the threads).  It also reminds one to think about variable scope/lifetime especially in the context of ASP.NET. 

An interesting day and I ran into some code that made interesting (and arguably not necessary use of a static member variable).  More and more I feel that static member variables (whether hidden by a property accessor) will bite you in the ass unless they were really meant to be readonly (WORM - write once read many) variables. 

Two interesting things:

1. I noticed this behavior and saw that the fantastically smart Chris Brumme had good things to say about on DevelopMentor's DOTNET List.   It's kind of a DUH moment when you realize it of course it should work that way.   Definitely don't count on the constructors of static fields marked with ThreadStatic.

2. Don't slap a [ThreadStatic] attribute on a static member when you're operating within ASP.NET as chances are you don't control the thread life...you inherit a worker thread.  ThreadStatic gives you thread local storage, not HttpContext local storage!  If you need to store something away to be used later in the same HTTP request, think about my favorite ASP.NET class, the little-known and not-used-enough System.Web.HttpContext.Current.Items (aside: great article by Susan Warren on Context).  In ASP.NET your code is run on a WorkerThread from the 25 or so threads in the default ASP.NET worker thread pool and the variable that you think is "personal private to your thread" is personal private...to you and every other request that this worker thread has been with.  Under load you may well find your variable modified.

To sum up places to stash things in ASP.NET:

Object Description
Application A key/value pair collection of values that is accessible by every user of the application.
Cache The ASP.NET Cache object, which provides programmatic access to the cache. Arguably a fancier face on Application.
Items A key-value pair collection that you can use to pass information between all of the components that participate in the processing of a single HTTP request. This is a great place to put things that need to be shared between ASP.NET pages and components farther downstream that will inherit the current HttpContext.
Session A key/value pair collection of values that are accessible by a single user of the application (When using InProc Session in ASP.NET 1.0 Session is really just a pretty indexed-by-cookie-guid face on the Cache object!)

When using ASP.NET think twice, then think again, before throwing that static (or Shared) keyword in there.  Perhaps there is a scope better suited for what you're trying to do.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

More .NET Purity discussions...

May 16, '03 Comments [2] Posted in Web Services | ASP.NET
Sponsored By

Lots of good debate and discussion on the Myth of .NET Purity from a number of very nice people as well as some nice links and comment threads.

Some people were a little taken aback and invoked Rotor and Mono to illustrate the importance of Purity and Code Portability.  I replied in a few comments posts, but re-print my position here:

One fellow agreed and said "If you want to do cool stuff the vise gets a bit tighter."

Another fellow mentioned the JVM and the CLI to which I responded: Note that you started using "CLI" in your sentence, rather than the ".NET Framework" or the "CLR." Certainly the CLI (common language infrastructure) as a concept is great and is obviously portable, having been ported as Mono and Rotor. But I'm not talking about the CLI. Rather, we should remember the underneath any layer of abstraction (leaky or not) there is an implementation. The point of my article was to remind folks that the Microsoft Windows implementation - the CLR and .NET BCL (base class library) - depend HEAVILY on the underlying behavior, libraries and services of the Windows OS. Code Portability (certainly desirable for some, less so for others) is certainly possible at the C# and IL level, but writing cross CLI implementation C# is no different than writing cross platform "C." Think about that. When writing cross platform code (often confused with 100% whatever, and there's a difference!) one has to consider: compiler behavior, interfaces, the OSs underlying implementation of the API, the level at which the API was written, etc.

One surely can't expect a very complex C# Winforms app with all the fancy GDI+ goodness and user controls to just work on Mono (unless I'm missing something) - not until the underlying implementation of ALL the dependancies are written and implementing using whatever Linux OS primitives are required to provide these features.

My rant was originally prompted by a fellow who was saying that he was writing some WinForms to ASP.NET Web Services app and that he was writing it in "100% Pure .NET" to INSULATE HIMSELF FROM RISK in some way. Like he'd be protected and have code portabilty if he just made sure to do it all in .NET. And that is a Myth. Code and life are a lot more complex than a sound bite like "100% .NET." - Scott Hanselman

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

See you at TechEd! I'm giving DEV389.

May 15, '03 Comments [0] Posted in Web Services | TechEd | Speaking | XML | Tools
Sponsored By

I'm confirmed to speak at TechEd 2003 in Dallas in June.  I'm going to give a mid-level talk about XML Web Services with WSDL as the fulcrum.  I'll talk about the need for a contractual agreement to exist between business entities and computers.  I'll walk up the conceptual stack, transport, syntax/structure, semanetics via rich types, business messages, and end points described with WSDL. I'll do a lot of sniffing and looking at SOAP on the wire, and explore proxy generation with XSD.exe and WSDL.exe.  Probably I'll spend a lot of time at the command-line and jumping between 4 or 5 different tools that AREN'T Visual Studio.  It's nice to point out at towards the end of the talk that we have been moving seemlessly between XML tools (many not from Microsoft), creating, editing, generating schemas, making WSDL, generating proxy code.  It's a nice reminder to the people in the audience who STILL haven't used Web Services that there ARE standards around this stuff!  And while all standards evolve, in this case the wire protocol is transparent.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

The Myth of .NET Purity

May 13, '03 Comments [8] Posted in Web Services
Sponsored By

As promised earlier I've posted a personal rant on The Myth of .NET Purity, that I submit for your perusal.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Woogle -> Google for your Desktop

May 13, '03 Comments [4] Posted in Web Services
Sponsored By

For a long time, I've wondered why Google can search the whole freak'n internet in < 1 second, but it takes Windows minutes to search my little hard drive.  Scott has me thinking, what good are folders?  Actually, folders are great, but what good is a massive hierarchy of folders that all roll up under a common root?  Does anyone really want to find anything by starting at C:?  If you had Google for your computer, would you use anything else?  Maybe in a future version of Windows, the desktop should just be a search form.  Woogle, anyone? [Early Adopter Weblog]

Preach on my brothers!  I need to write a .NET application that lets me exploit the Indexing Service...We all have Google on our desktops...it's right here and has been for years - the Indexing Service Query Form in the MMC.  It's just not friendly and Explorer appears not to care.  What IS the sordid relationship between the Indexing Service (that obstensibly gets turned on by the Explorer Search but never used!) and the Shell? 

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.