>>>After more thinking about this, I think it is normal we are not allowed to assigned a NameObjectCollectionBase object to another one as its main root would differ at first making sense for the error message I am getting at the designer level. It might work for a dictionary but not for a NameObjectCollectionBase object.
>>>
>>>I will have to try with the locking mechanism instead.
>>>
>>>In the meantime, if you see a workaround with the 2nd approach or if you would know why I am getting this, feel free to let me know.
>>
>>NameObjectCollectionBase or dictionary - the class is does not matter
>>
>>
>>I've used the volatile keyword http://msdn.microsoft.com/en-us/library/x13ttww7.aspx
>>See also here http://www.yoda.arachsys.com/csharp/threads/volatility.shtml
>>
>>
>>

>>	public class AClass
>>	{
>>		private volatile Dictionary<string, string> Tables_;
>>	
>>		public Dictionary<string, string> Tables
>>		{
>>			get; private set; 
>>
>>		}
>>
>>		public AClass()
>>		{
>>			// Initialize Tables
>>			Tables_ = new Dictionary<string, string>();
>>			Tables_.Add("1", "one");
>>			Tables_.Add("2", "two");
>>		}
>>		public void ReInitializeTables()
>>		{
>>			// do not set to null
>>
>>			Dictionary<string, string> tmp = new Dictionary<string, string>();
>>			tmp.Add("3", "three");
>>			tmp.Add("4", "four");
>>
>>			Tables_ = tmp;  // assign new initialized object
>>
>>		}
>>	}

>IIRC, VB doesn't have 'volatile' - maybe Monitor class ?

Didn't know that - maybe Thread.VolatileRead() then ? http://msdn.microsoft.com/en-us/library/system.threading.thread.volatileread.aspx


>But, still not understanding enough about Michel's system, I'm not sure locking at this level will resolve the issue. True - it will guarantee that the hit does not receive an inconsistent or out of date version of the data on entry. But it does not prevent the reverse - data being changed on another thread before the hit exits. The only way to do that would be to hold a lock on the 'hit' thread until it completed - obviously not practical for a IIS site ?


> obviously not practical for a IIS site

That is why I have dropped the lock()

> But, still not understanding enough about Michel's system

I don't either - the only thing that I focussed on was from another thread - something like a null reference

So I thought that maybe he was setting the property to null, and afterwards reinitialize it
I have focussed on that - never let the property become null

But - it's guessing