Orchestrations that use Singleton classes with Dispose pattern

Recently I had to convert an orchestration from singleton to non singleton. Orchestration was implemented as singleton as it had to process the incoming requests in sequential order. As sequential processing was no longer a requirement, I was being assigned to convert it to non singleton.

It was a cake walk all through except for reading the values from registry. In singleton orchestration, it can read and store values from registry (ok, there are still some organizations that depend on registry for lot of configuration, .. legacy) before the start of loop and was fine. When converted to non singleton,  I no longer have the freedom to go registry for every orchestration instance.

Approach 1 (not recommended):

Started with a singleton .Net class which caches the registry values and uses PInvoke to monitor the registry values.  Since it uses PInvoke, the class needs to implement Dispose pattern.  As the class is used by the orchestration instances, it is not possible to call Dispose() method from an orchestration as it is being used by other. And Finalization is the only way for the class to get Garbage Collected; Finalization is not only costly but also there is no order in which Finalize() gets executed. And not a recommended solution.

Approach 2:

Instead of using PInvoke to monitor the registry to avoid invoking the Dispose,  we can use polling to update local cache for every 5 minutes (configurable) with the help of System.Threading.Timer along with System.Threading.ReadWriteLock to control the access to the shared variables.  For implementation details look into BizTalk 2006/sdk/scenarios.

The conclusion,  singleton .Net Classes which implement Dispose pattern is not a good fit with non singleton Orchestrations.