更新： November 2007
LINQ to SQL 支援開放式並行存取 (Optimistic Concurrency) 控制。下表說明 LINQ to SQL 文件中與文件中開放式並行存取相關的詞彙：
| 詞彙 | 說明 |
| 並行 | 兩位以上的使用者同時嘗試更新相同資料庫資料列的情況。 |
| 並行衝突 | 兩位以上的使用者同時嘗試將衝突值送出給資料列的一個或多個資料行的情況。 |
| 並行控制 | 用來解決並行衝突的技術。 |
| 開放式並行存取控制 | 此種技術會先檢查資料列中的其他交易是否已變更值，才允許送出變更。 與「封閉式並行存取控制」(Pessimistic Concurrency Control) 不同的是，後者會鎖定資料錄，避免並行存取衝突。
稱為「開放式」(Optimistic) 控制的原因是它會將某個交易干擾另一個交易的機會視為不可能。 |
| 衝突的解決方式 | 透過再次查詢資料庫，然後調整差異，以重新整理衝突項目的處理流程。 重新整理物件時，LINQ to SQL 變更 Tracker 會保留下列資料： -
一開始取自資料庫且用於更新檢查的值。 -
來自後續查詢的新資料庫值。
LINQ to SQL 接著會判斷物件是否發生衝突 (也就是，它的其中一個或多個成員值是否變更)。如果物件衝突，則 LINQ to SQL 會接著判斷它的哪個成員發生衝突。 LINQ to SQL 發現的所有成員衝突都會加入至衝突清單中。 |
在 LINQ to SQL 物件模型 (Object Model) 中，「開放式並行存取衝突」(Optimistic Concurrency Conflict) 會在下列兩個條件都符合時發生：
解決這項衝突包括探索哪些物件成員發生衝突，然後決定要採取的動作。
例如，在下列案例中，User1 查詢資料庫中的資料列，開始準備更新。User1 會接收到值為 Alfreds、Maria 和 Sales 的一個資料列。
User1 想將 Manager 資料行的值變更為 Alfred，並將 Department 資料行的值變更為 Marketing。但是在 User1 送出那些變更之前，User2 就已經先送出變更給資料庫。因此，現在 Assistant 資料行的值已變更為 Mary，而 Department 資料行的值已變更為 Service。
如果 User1 現在嘗試送出變更，則送出會失敗，而且會擲回 ChangeConflictException 例外狀況。因為 Assistant 資料行和 Department 資料行的資料庫值並不是所預期的值，所以會發生這種結果。因此表示 Assistant 和 Department 資料行的成員會產生衝突。下表將摘要說明這種情況。
| | Manager | Assistant | Department |
| 原始狀態 | Alfreds | Maria | Sales |
| User1 | Alfred | | Marketing |
| User2 | | Mary | Service |
您可以使用不同方式來解決這類衝突。如需詳細資訊，請參閱 HOW TO：管理變更衝突 (LINQ to SQL)。
您可以偵測和解決任何精細度等級的衝突。其中一種極端的做法是，使用三種方式的其中一種方式來解決所有的衝突 (請參閱 RefreshMode)，而不考慮其他事項。另一種極端的做法是，指定每個衝突成員之每種衝突類型的特定動作。
支援衝突探索和解決的 LINQ to SQL 型別
LINQ to SQL 中支援開放式並行存取衝突解決的類別和功能包括：
其他資源