Locator locking

Sep 11, 2006 at 9:12 PM
Using OB in a custom internal web application with a thin facade on top (provides XML config). We are in perf tuning phase and observing quite a number of threads that are waiting on the lock that guards access to the locator. What influenced the OB design such that the lock is taken before the strategy chain begins execution? {Rather than taking it only once the it has determined that the object is indeed a singleton and needs to be placed in (or fetched from) the locator/lifetime container} We are considering refactoring the locking behavior to move the lock creation into the Singleton strategy.

Does this approach raise any alarm bells with you?
Coordinator
Sep 12, 2006 at 2:47 AM
The intention was to lock for the entire run. If you don't lock for the entire run, you might make incorrect decisions based on the state of the locator (for example, ending up creating two instances of a singleton object.
Sep 12, 2006 at 4:50 PM
Brad,
The idea I am considering is moving the lock activity to the Singleton Strategy BuildUp method and only locking the locator once I can confirm that the item to build is a singleton (not an instance) and that the locator doesn't already contain the item. That would defer locking until the last possible moment and avoid locking for instance objects.

Does that sound correct to you?
Coordinator
Sep 12, 2006 at 11:48 PM
What is the scope of the lock? Does it begin when you realize that you're creating an object that is a singleton, and end after it's fully built? That might work. Beware of deadlocks based on exceptions during the buildup, of course (meaning, you probably can't use the C# lock keyword). I'll think on it... :)
Sep 13, 2006 at 12:34 AM
Yes, I had been thinking to place the lock within the SingletonStrategy (after determining that a singleton must be built). The call to BuildUp on the rest of the chain would be surrounded by the lock. I suppose it could alternatively be placed within a (custom) CreationStrategy class. Moving it there would defer the lock until the very last moment (just prior to creation).

Would you please elaborate on your concerns on exception induced deadlocks? How would an exception within the build process cause a deadlock? How does the current code address this risk/concern?

Thanks for your help.