I'm on the road this week, but thought I'd post a quick follow up to my posts on creating configuration section handlers for your .NET applications.

This is a case where you may "know" something, but you do something, which leads to really  "understanding" that thing. In this case, I knew that config handlers are cached - the config file is only read once, and the data (objects etc) that you create in the handler are then cached. This is done for efficiency, and that makes sense.

In a project I was working on I created real business objects from my configuration file. In their role as business objects, they maintained selection sets on particular layers (hence the config file) in an ArcIMS application. And actually stored them in Session.

This all worked fine, and things were progressing until two of us hit the app on the same server at the same time. For some reason, we appeared to be sharing the same selection set. I would select a feature, and it would appear on my map, and and the other users map. This caused a few minutes of head scratching before I clued into it - the objects that were created in the config section handler were cached by ASP.NET, and thus each session was accessing (pointers to) the same instance of the objects - thus the selection set appeared to be shared.

Interesting behavior, if that's what you're after. This was easily solved by whipping up a quick SimpleClone method that I could invoke prior to setting other properties and sending the object into session (I opted not to implement IClonable because I did not want to actually clone the whole object hiearchy - just a simple clone of the configuration data). This solved the issue, and showed that despite "knowing" something, sometimes it's hard to see the implications.

Thus, my suggestion is to only create <myobject>Config classes from Configuration handlers - this will help avoid the tendancy to simply use the classes directly, and possibly stuff them into session where you'll get unexpected results.