I have adjusted the code which handles the first hit on a site. I had to make a locking adjustment because one of the process was a group type approach so I had to make sure that only one would go in there. Basically, it goes like this when the application starts for a Web site or when it is being recycled:

            ' If this is the first hit
            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 could end up in a real mess
                SyncLock loObjectLock

                    ' 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.lInitializeWeb Then

                        ' Do initialization here

                        oApp.lInitializeWeb = True
                    End If

                End SyncLock

            End If

Based on my tests, this seems to have resolved the issue. So, while oApp.IInitializeWeb is not set to True, it might well be possible two users are accessing the Web site at first. So, I have added a property at the application level to tell the hit that the Web initialization has been done. So, the first one gets in and lock the thread. When the thread is unlocked, the next one will go in but will skip it as the oApp.lInitializeWeb property has been set.

lFirstHit controls the first hit on the site. So, lFirstHit turns True once this is done so the logic of a hit will never go in this code for as long as the application runs after.

I would just like to verify if someone could see something wrong in there.