0

データベース呼び出しを行うために利用する Linq-to-SQL DataClasses オブジェクトがあります。私はそれを次のようにラップしました：

  public class DataWrapper {

    private DataClassesDataContext _connection = null;
    private static DataWrapper _instance = null;
    private const string PROD_CONN_STR = "Data Source=proddb;Initial Catalog=AppName;User ID=sa;Password=pass; MultipleActiveResultSets=true;Asynchronous Processing=True";

    public static DataClassesDataContext Connection {
      get {
        if (Instance._connection == null)
            Instance._connection = new DataClassesDataContext(DEV_CONN_STR);

        return Instance._connection;
      }
    }

    private static DataWrapper Instance {
      get {
        if (_instance == null) {
          _instance = new DataWrapper();
        }
        return _instance;
      }
    }
  }

このラッパーを使用して、次のようにストアド プロシージャ呼び出しを行うスレッドがいくつかあります。

DataWrapper.Connection.Remove_Message(completeMessage.ID);

ごくまれに、DataClasses オブジェクトが例外をスローします。

ExecuteNonQuery には、オープンで使用可能な接続が必要です。接続の現在の状態は閉じています。

私は接続の状態をまったく管理していません-Linq-to-SQLがこれを処理する必要があると考えました。電話をかけるたびに接続の接続状態を確認し、閉じている場合は開くことができましたが、それはハックのようです。

SQL が接続を強制的に閉じる可能性を処理するために、接続文字列にMultipleActiveResultSets=trueandを付けてみましたが、それは役に立たなかったようです。Asynchronous Processing=True

何か案は？

4

1 に答える 1

1

DB接続オブジェクトをキャッシュして再利用しないでください...特に複数のスレッドから。

DB にアクセスする必要があるたびに、接続を開き、操作を実行し、接続を閉じる必要があります。

基盤となるデータベース アクセス インフラストラクチャ (ASP.NET/OLEDB) は、ほとんどの再接続コストを (事実上) ゼロに削減する方法で接続プールを管理します。

于 2013-03-27T18:41:44.037 に答える