>>>Based on that reference, it does seem in fact that the same worker process can handle simultaneous hits. Thus, the situation I have is that, even if I have a locking mechanism at the high level of process to reload the data dictionary, one hit for the same worker process might already be passed that marker. So, while the data dictionary is being reloaded, the other hit in progress might fails on a data request.
>>>
>>>Thanks for the reference on "More on". I will take note of that.
>>
>>I googled [iis7 worker process threads multiple hits]. There is some interesting information at:
>>
>>http://stackoverflow.com/questions/2151251/asp-net-web-garden-how-many-worker-processes-do-i-need
>>
>>http://forums.asp.net/t/1447626.aspx
>>
>>Based on those, it looks like you have a couple of choices:
>>
>>- keep using 4 worker processes, and limit each one to a single thread. Then you will not encounter threading issues
>>
>>- modify your worker processes to be thread-safe. You could then specify how many threads each should be allowed to run. Maybe you could switch to 2 worker processes (for redundancy), each with a reasonable thread count.
>>
>>Looking at those posts, I'm not sure there would be any performance improvement in running 4 worker processes with 1 thread each, vs. running 1 WP with 4 threads.
>
>Thanks, all that is good information.
>
>I have II6 on everywhere I have to maintain those servers. So, some of the settings may not apply.
>
>I understand that limiting a worker process to be single threaded will resolve the issue. But, I am not ready to loose the multithreading functionality. Going single thread is ok when we start and have a basic infrastructure. But, to where I have evolve the framework I am working with, I can adjust where necessary to overcome this situation. I need to focus on keeping the multithreading.
>
>Those articles and similar ones sometimes refer to session states being lost and so on. That is normal as each worker process runs in its own environment, thus the oApp shared object I earlier mentioned, but also in reference to many persons who had problems where they rely on session state. In my case, I do not have anything like that. Everything in regards to session related storage mechanism is handled at the database level.
>
>But, in my situation, I only get a problem, and that is very rare, like I said, is when I have to update the data dictionary, which is all done from the Web, so as all other SQL Server management. So, if I update a field to validate for a minimum length of characters being entered, I update the data dictionary from the Web. Then, the current worker process doing the request will reload what is necessary to be updated, will update the Admin.DataDictionary value and other worker processes will know that a reload is necessary seeing that their Admin.DataDictionary value is not the same as the one in the database. So, basically, I can run millions of hits before I get such a situation. I can also do 200 data dictionary maintenances without having this problem. But, sometimes, when a hit from worker process 1 is in progress and another hit from worker process 1 is locking any upcoming hits, the time it takes the reload the shared oApp environment, this might have the other hit in progress to loose the ability to read the proper oApp content as it is being reconstructed.
>
>So, one approach would be to focus on simply adjusting my data class wherever it is needed to verify for the flag and retry on a timeout and that should enhance the logic. It takes a fraction of a second for the oApp shared object to be reconstructured. So, if a hit in progress detects that a reload of the data dictionary is currently occuring, it will just retry on timeout. Thus, in the next second, the process will go on. But, as I said, this happens only when we do maintenance. So, it is not as if we wouldn't know the reason for this situation. As I know what is causing this, it makes it easier to find a workaround.
>
>So far, I have been thinking of something like that:
>
>

>        ' If the data dictionary is available
>        ' If a simultaneous hit on the same worker process reloads the data dictionary, this might make the data
>        ' dictionary not available to the application.
>        Public Function DataDictionaryAvailable() As Boolean
>            Dim lnCounter As Integer = 0
>            Dim lnDelay As Integer = 250
>            Dim lnRetry As Integer = 20
>
>            ' We will retry 20 times
>            For lnCounter = 1 To lnRetry
>
>                ' If the data dictionary is available
>                If oApp.lInitializeAdmin Then
>                    Exit For
>                Else
>
>                    ' If we have not reach 20 times
>                    If lnCounter < 20 Then
>
>                        ' Wait for a timeout before retrying
>                        System.Threading.Thread.Sleep(lnDelay)
>
>                    Else
>                        ErrorSetup(, "The data dictionary is not available.")
>                        Return False
>                    End If
>
>                End If
>
>            Next
>
>            Return True
>        End Function
>

>
>And, from where needed in the data class, before accessing the data:
>
>

>                    ' Just in case a simultaneous hit on the same worker process reloads the data dictionary
>                    If Not oProcess.DataDictionaryAvailable() Then
>                        Return False
>                    End If
>

>
>Basically, if the worker process is reloading the data dictionary, oApp.lInitializeAdmin will be False. So, in normal situation it is True and will simply bypass the logic in DataDictionaryAvailable(). But, when a reload will occur, it will then retry at each quarter of a second for 20 times, where after one of two tries, it should go.
>
>This might not been seen as thread safe. As, there could always be a failure. But, at least, until I find a better way, it should diminish the possibilities of having that situation. To make it more thread safe, I could establish a way for the hit doing the reload of the data dictionary to wait for other hits from the same worker process to complete. But, I am not too sure about how to detect that. There might be a way to detect that from .NET classes. If that would be possible, it would resolve the issue, I wouldn't need the above code and it would make it thread safe. Because, once the reload of the data dictionary occurs, a locking is in place. So, all upcoming hits from the same worker process are falling in the lock until the reloading completes. Then, those pending hits are simply jumping over the lock as oApp.lInitializeAdmin tells them that everything is loaded. There was some threads not so long ago about the locking mechanism to handle this. You probably have seen those.

Looks like reasonable defensive coding to me. Carried to an extreme, it means assuming any call you make may fail, and coding to handle that.