私はあなたができるとは思いません(それらのIISワーカーに共有メモリ内のオブジェクトを何らかの方法で使用させることができない限り)。
これはスコープの問題です。シングルトンインスタンスは、スコープとしてプロセススペースを使用します。そして、あなたが言ったように、あなたの実装は今や複数のプロセスにまたがっています。 定義上、ほとんどのオペレーティングシステムでは、シングルトンは単一のクラスインスタンスまたはオブジェクトに関連付けられているため、特定のプロセススペースに関連付けられます。
本当にシングルトンが必要ですか?これは、そのパターンを使用する前に尋ねる非常に重要な質問です。ウィキペディアが言うように、それをアンチパターン(またはコードの臭いなど)と考える人もいます。
動作する可能性のある代替設計の例には、次のものがあります...
- 複数のオブジェクトを中央ストアに対して、または相互に同期させることができます。
- 該当する場合は、オブジェクトのシリアル化を使用します。
- Windowsサービスと何らかの形式のIPCを使用します。System.Runtime.Remoting.Channels.Ipc
大規模なWebサイトのオプション3が好きです。コンパニオンWindowsサービスは、一般的に大規模なWebサイトで非常に役立ちます。メールの送信やバッチジョブなどの多くのものは、フロントエンドの処理ワーカープロセスからすでに切り離されている必要があります。シングルトンサーバーオブジェクトをそのプロセスにプッシュし、IISワーカープロセスでクライアントオブジェクトを使用できます。
シングルトンクラスが状態を共有する、または初期状態を共有するだけの複数のオブジェクトで機能する場合は、オプション1と2がそれぞれ機能するはずです。
編集
あなたのコメントから、分散キャッシュの形の最初のオプションがあなたのために働くはずだと思われます。
そこには多くの分散キャッシュの実装があります。
- Microsoft AppFabric(以前はVelocityと呼ばれていました)は、この分野へのごく最近の動きです。
- MemcachedASP.Netプロバイダー
- NCache(MSDN Article)-OutProcサポートのカスタムASP.Netキャッシュプロバイダー。そこに他のカスタムキャッシュプロバイダーがあるはずです。
- WindowsサービスとIPCを使用して独自の分散キャッシュを展開する(オプション3)
PS。あなたは特にチャットを調べているので。Comet(ASP.NETのComet実装?、WebSyncなど)を調査することを強くお勧めします