I am using SyncLock to make sure that each worker process only loads the data dictionary once. Then, it is shared across oApp which is visible to all incoming hit from the same worker process. It goes like this:

            ' If this is the first hit for the same worker process (w3wp.exe - Task Manager)
            ' It is important to know that if the application pool is defined to load up to four instances of the
            ' worker process, for example, that those additional worker process have their own independent environment
            ' and cannot benefit from the shared oApp object. So, each of them would go in this logic in their first hit.
            ' The logic is made that if the same worker process receives an incoming hit during initialization time that
            ' only one would do the initialization process.
            If lFirstHit Then

                ' Make sure to lock the thread otherwise, it two simultaneous hits are entering
                ' here, which could be the case when the application starts, you will end up in a real mess
                ' at startup or at recycle
                SyncLock oApp.oObjectLock

                    ' If the application initialized has been completed by someone else, then, we can skip that part.
                    ' The scenario here is that the first one who get into there will do the setup. But, we need to avoid
                    ' the other one to setup again.
                    If Not oApp.lInitialize Then

                        ' Load the data dictionary
                        If Not LoadDataDictionary() Then
                            Return False
                        End If

                        ' Add the IISApplicationCycle
                        loInsertRow.cAlias = "IISApplicationCycle"
                        loInsertRow.ParameterAdd("Mode", oApp.nApplicationMode)
                        loInsertRow.ParameterAdd("IP", cIP)
                        loInsertRow.ParameterAdd("ProcessID", oApp.nProcessID)
                        If Not loInsertRow.InsertRow() Then
                            Return False
                        End If

                        oApp.lInitialize = True
                    End If

                End SyncLock

            End If

So, basically, as you might have guessed, lFirstHit is initialized to True when the worker process starts. So, this logic is only executed once per worker process. The reason there is a lock is to avoid simultaneous hit from the same worker process to initialize. So, the first that gets in, gets the lock. It initializes and set oApp.lInitialize to True. Then, it unlocks. So, the pending simultaneous hit will be able to proceed but will not enter into the logic as the first verification in it is oApp.lInitialize which will tell it that it is True.

This works pretty well. I have been using that approach for a few weeks now and all seems to be ok.

Well, almost ok because I have a weird situation that happens from time to time. It is extremely difficult to simulate. But, take a look at the attached JPG and you will see that I have two records which have been created with the same process ID at the same time, thus after I sent a new compile. This means the lock didn't work at 100% as it allowed both simultaneous hit from the same worker process to get into this loop. It shouldn't have done it as there is a lock for the first one that gets in. And, once that particular one finishes the loading of the environment, it says that it is initialize and releases the lock. The pending one should simply skip it.

As I said, this works at almost 100%. But, from time to time, I get this situation.

So, again, by looking at the JPG file, we can clearly see that there is a problem with the lock. Can someone point me to what it could be?

The image shows the IISApplicationCycle table, which is the record which is being inserted to indicate that a new worker process just got loaded.