I originally posted about this issue in the General ASP.NET forum [reference], but have isolated the problem to a conflict with IIS Web Gardens and so I'm cross-posting it here.

Summary: My application works as expected when used with a single worker process.  When shared between multiple worker processes, however, one process (presumably the first) behaves as expected, where as the second exhibits problems which seem related to thread management.  There are two specific cases.

1. CurrentUICulture.  I have a custom cache parameter based on Thread.CurrentUICulture.  One of the worker processes interprets this properly (returning a cache snapshot for each unique UICulture).  The second always returns the first snapshot created (regardless of which UICulture it was created for or which is requested). 
2. Synchronized Hashtable.  I have a custom business object which exposes a Hashtable as a public static member (should be threadsafe).  Additionally, it implements synchronization to avoid potential conflicts during multiple writes.  The object works as expected on one worker process; on the other, however, it exhibits indications of multi-threading violations (e.g., there are version conflicts which suggest overwritten states). 

I understand that this behavior is hard to isolate w/out code samples.  Given, however, that the code operates as expected in a single worker process environment I am interested in direction on what impact web gardens might have on threading issues, especially thread safety (I could speculate how the first issue could be a multi-threading violation based on how .NET potentially stored its OutputCache index). 

I've worked around this issue by disabling web gardening on the server.  However, I'd like to understand the core issue and, ideally, make the application more environment-agnostic.  Any suggestions on where to start digging would be appreciated.

Hi,

As Per MSDN article :

The old motto "not everything that shines is gold" is an apt quotation here. Web gardening enables multiple worker processes to run at the same time. However, you should note that all processes will have their own copy of application state, in-process session state, ASP.NET cache, static data, and all that is needed to run applications. When the Web garden mode is enabled, the ASP.NET ISAPI launches as many worker processes as there are CPUs, each a full clone of the next (and each affinitized with the corresponding CPU). To balance the workload, incoming requests are partitioned among running processes in a round-robin manner. Worker processes get recycled as in the single processor case. Note that ASP.NET inherits any CPU usage restriction from the operating system and doesn’t include any custom semantics for doing this.

I understand that and expect that there will be two copies of the cache (as well as any static objects) - which is behavior I was seeing.  What was unexpected, however, is that the code was not operating the same on each process; the code behaves perfectly in a single process mode, but exhibited signs of thread conflicts with web gardening.  Since the memory is partitioned per process I didn't expect this.  At some point I may pick this up again in order to better isolate the issue.

See www.iis.net for more on IIS.

Jeff