3

私の ASP.NET MVC プロジェクトには、Structuremap を介してインスタンス化され、シングルトンとして構成されたクラスがあります。

ASP.NET は本質的にマルチスレッド化されており、Singleton パターンはデフォルトでスレッドセーフではありませんが、問題は発生しますか?

シングルトンとして構成されたクラスに対して複数のインスタンスが返されるという問題に直面しました。この問題は、インスタンスが異なるスレッドから要求されていることが原因である可能性があります。

編集：この質問について、より詳細な説明が与えられています。複数のインスタンスを返すシングルトンのストラクチャマップ

EDIT2：これは私のクラスが何をするかの説明です

class DerviedClass: BaseInterface
{
   ISession session

   DerivedClass()
   {
      session = ObjectFactory.GetInstance<ISession>();
   }

   public bool DoWork
   {
       return session.QueryOver<MyTable>().RowCount() > 0;
   }
}
4

2 に答える 2

3

拡張バージョンを考慮に入れると、次の例が表示されます。DerviedClassこれは非常に危険であり、多くの問題を引き起こす可能性があると言えます。

私の懸念：

1) ASP。NET+ NHibernate==リクエストISessionごと。つまり、アプリケーションが起動すると(最初のリクエストによってトリガーされる可能性が最も高く、自動再起動が適切に行われている場合はより頻繁に発生する可能性があります)、Singleton が作成され、Current Requestごとのインスタンス、つまりFirst Requestが提供されます。ISession

少なくとも、現在のリクエストに関連していることを確認するために、必要なときにいつでもISession受信する必要があります。Factory

2) コンストラクターで作成された NHibernateがCurrent RequestISessionに依存しないことを意図している場合、次のことを意味する可能性があります。

  • それは長時間実行され、開かれており、より多くの要求の間で閉じられていません - ロックの問題の可能性があります。または
  • 現在のリクエストに基づいていない、open/close ISession の管理が必要です。

ポイントは、ここでは Singleton パターンの利点が見られないということです。私たちは、共通の要求独立したものを必要とせず、提供しません。

リクエスト (およびそのセッション スコープ) に依存するデータを返します。だから、私が使用することをお勧めします：

.HybridHttpOrThreadLocalScoped()

リクエストごとにインスタンスを作成するオーバーヘッドは、論理的なライフサイクルの使用の利点と比較して何もありません.

しかし、はい、これは単なる私の提案です...多くの潜在的な問題が見られるためです（ロック、意図しない変更、コミットされる可能性のあるセッション内のダーティオブジェクトなど）

于 2013-06-08T17:33:53.907 に答える
1

次のように、すべてのプロパティ セット ブロックがロックを使用するようにして、シングルトンをスレッド セーフにする必要があります。

public int Counter
{
    get { return _counter; }

    set
    {
        lock(_counterLock)
        {
            _counter = value;
        }
    }
}

private int _counter = 0;

private object _counterLock = new Object();
于 2013-06-04T13:51:37.553 に答える