觀察LINQ to SQL DataContext的連線開啟時機

static void log(string msg)

{

    Console.WriteLine("{0:HH:mm:ss.fff} {1}", DateTime.Now, msg);

    System.Threading.Thread.Sleep(2000);

}

static void Main(string[] args)

{

    MyLabDataContext db = new MyLabDataContext();

    log("DataContext created");

    var q = from o in db.Players

            select o;

    log("LINQ defined");

    Console.WriteLine(q.Count());

    log("Get the row count");

    Player p = new Player()

    {

        UserName = "Darkthread",

        RegDate = new DateTime(2009, 1, 1),

        HiScore = 65536

    };

    db.Players.InsertOnSubmit(p);

    log("InsertOnSubmit");

    db.SubmitChanges();

    log("SubmitChanges");

    db.Dispose();

    log("Disposed");

    Console.Read();

}

# Will 保哥 said on 21 October, 2009 03:01 PM

依我個人的經驗來說，在 DataContext 不利用 using 確保資源被釋放的情況下，的確是有機會導致資源耗盡的情況！

我們先前有寫過一支 Windows Service 程式，是長時間不中斷在執行的，結果不到兩個月的時間，客戶端就回報在 Event Log 中發現有幾次 OutOfMemory 的情況 (很少量, 但有! )，導致服務被終止，雖然可以在服務管理員中有「失敗恢復」的設定，但畢竟還是造成程式不穩定！

當我們改用 using 之後就沒再發生問題了。

# Jeffrey said on 21 October, 2009 04:36 PM

感謝保哥寶貴的經驗，為"加上using有利無害"再多添一筆證言。雖然以茶包射手的辦案標準來看，這個案例還不算為"using與OutOfMemory絕對相關"提供了"直接鐵證"，除非再把using拿掉，確保相同的使用條件下再試一段時間。但要在正式環境長期使用觀察(故意改回可疑寫法等出錯，會被客戶殺死吧?)，又要排除其他變因的干擾，工程浩大，代價高昂。我想在本例中，加上using免除疑慮的做法100%正確。

我對DataContext在何種情況下會發生Connection資源未釋放的議題很感興趣，有空再來研究一下好了。再次感謝保哥提供的經驗分享!

# Ark said on 21 October, 2009 09:37 PM

挖丟災...

# aliku said on 29 October, 2009 07:40 PM

對有實做 IDisposed 加上 using 是個好的習慣.

感謝分享 !!

# justfriend said on 02 November, 2009 02:18 AM

你好，想請問【最後一刻開啟、用完立即關閉】的寫法和用connection pool的寫法，那種比較好？或是什麽情況下用【最後一刻開啟、用完立即關閉】，什麽情況下用connection pool呢？

# Jeffrey said on 02 November, 2009 07:01 AM

to justfriend, 在ADO.NET預設在做cn.Open()、cn.Close()時，就有動用到Connection Pool，用完立即關閉的連線會被放入Pool中，下次再開啟時會被再拿來重覆使 用，二者並非互斥的，而【最後一刻開啟、用完立即關閉】的對象其實就是Connection Pool裡的已開啟連線。

# justfriend said on 02 November, 2009 11:31 PM

原來是ado.net已處理掉connection pool的機制，謝謝你的回覆 ^^。

你的看法呢?

標題 (必要的) 

姓名 (必要的) 

你的URL (選擇性的)

意見 (必要的) 

Remember Me?

請輸入以上的數字:

搜尋