NOLOCK默認爲每個請求創建一個ObjectContext的爲EF4

是否有此代碼的任何副作用：NOLOCK默認爲每個請求創建一個ObjectContext的爲EF4


///This code runs per request 
public static MyObjectContext CreateEntity() 
{ 
    MyObjectContext db=new MyObjectContext(); 

    db.Connection.Open(); 
    var con = (SqlConnection)((EntityConnection)hi.Connection).StoreConnection; 
    SqlCommand cmd = new SqlCommand("set transaction isolation level read uncommitted",con); 
    cmd.ExecuteNonQuery(); 

    return db; 
}

現在「DB」的實例將運行ReadUncommited模式？

來源

2011-04-26 Serhat Dincel

副作用是，您必須手動處理您的連接，並且連接在整個生命週期內都由上下文保存。它也在整個生命週期內保持打開狀態，效率較低。

另一個副作用是讀取未完成的隔離級別本身，使用相當危險，因爲它允許讀取未被取消的事務數據。

爲什麼你需要這個？ EF默認使用數據庫服務器的默認事務隔離模式。對於SQL服務器，它被讀取提交。 EF在默認情況下不會保留記錄上的鎖定，因爲每個讀取操作只是一個事務的一部分，持續時間僅限於讀取。只有SaveChanges將事務用於多個數據庫命令。

來源

2011-04-26 07:22:44

我有一張表（User_Notification）。該表具有沉重的插入負載。 – 2011-04-26 17:18:44

那麼只有在訪問這個表時才使用read uncommited呢？ – 2011-04-26 17:35:31

現在我已經在同一個問題上掙扎了好幾個小時。我們的數據庫團隊堅持將隔離級別設置爲READ UNCOMMITTED。我正在使用存儲命令在上下文級別執行此操作。但是，後續查詢失敗給我以下錯誤。 '您只能在READ COMMITTED或REPEATABLE READ隔離級別中指定READPAST鎖。'有些查詢默認使用READPAST鎖，並且我沒有在分析器中看到該查詢。有任何想法嗎？ – Praveen 2011-04-27 01:31:38

NOLOCK默認爲每個請求創建一個ObjectContext的爲EF4

回答

相關問題