다음을 통해 공유


낙관적 동시성: 개요

LINQ to SQL은 낙관적 동시성 제어를 지원합니다. 다음 표에서는 LINQ to SQL 설명서의 낙관적 동시성에 적용되는 용어를 설명합니다.

용어 설명
동시성 두 명 이상의 사용자가 동시에 동일한 데이터베이스 행을 업데이트하려고 하는 상황입니다.
동시성 충돌 두 명 이상의 사용자가 동시에 하나 이상의 행 열에 충돌하는 값을 제출하려고 하는 상황입니다.
동시성 제어 동시성 충돌을 해결하는 데 사용되는 기술입니다.
낙관적 동시성 제어 변경 내용 제출을 허용하기 전에 다른 트랜잭션이 행의 값을 변경했는지 여부를 먼저 조사하는 기술입니다.

동시성 충돌을 방지하기 위해 레코드를 잠그는 비관적 동시성 제어와 대조됩니다.

낙관적 제어는 한 트랜잭션이 다른 트랜잭션을 방해할 가능성이 낮다고 간주하기 때문에 그렇게 합니다.
충돌 해결 데이터베이스를 다시 쿼리한 다음 차이점을 조정하여 충돌하는 항목을 새로 고치는 프로세스입니다.

개체를 새로 고치면 LINQ to SQL 변경 추적기는 다음 데이터를 보유합니다.

- 원래 데이터베이스에서 가져온 값이며 업데이트 검사에 사용됩니다.
- 후속 쿼리의 새 데이터베이스 값입니다.

그런 다음 LINQ to SQL은 개체가 충돌하는지 확인합니다(즉, 하나 이상의 멤버 값이 변경되었는지 여부). 개체가 충돌하는 경우 LINQ to SQL은 다음에 충돌하는 멤버를 결정합니다.

LINQ to SQL에서 검색하는 멤버 충돌이 충돌 목록에 추가됩니다.

LINQ to SQL 개체 모델에서 다음 조건이 모두 충족되면 낙관적 동시성 충돌이 발생합니다.

  • 클라이언트가 데이터베이스에 변경 내용을 제출하려고 합니다.

  • 하나 이상의 업데이트 확인 값이 클라이언트에서 마지막으로 읽은 이후 데이터베이스에서 업데이트되었습니다.

이 충돌 해결에는 충돌 중인 개체의 멤버를 검색한 다음 수행할 작업을 결정하는 것이 포함됩니다.

비고

Always 또는 WhenChanged로 매핑된 멤버만 낙관적 동시성 검사에 참여합니다. 표시된 Never멤버에 대해서는 검사가 수행되지 않습니다. 자세한 내용은 UpdateCheck를 참조하세요.

예시

예를 들어 다음 시나리오에서 User1은 데이터베이스에서 행을 쿼리하여 업데이트를 준비하기 시작합니다. User1은 Alfreds, Maria 및 Sales 값이 있는 행을 받습니다.

User1은 Manager 열의 값을 Alfred로, 부서 열의 값을 마케팅으로 변경하려고 합니다. User1이 이러한 변경 내용을 제출하기 전에 User2는 데이터베이스에 변경 내용을 제출했습니다. 이제 Assistant 열의 값이 Mary로 변경되고 부서 열의 값이 Service로 변경되었습니다.

이제 User1이 변경 내용을 제출하려고 하면 제출이 실패하고 예외가 ChangeConflictException throw됩니다. 이 결과는 Assistant 열과 Department 열의 데이터베이스 값이 예상한 값이 아니기 때문에 발생합니다. 보조 및 부서 열을 나타내는 멤버가 충돌합니다. 다음 표에서는 상황을 요약합니다.

시스템 상태 매니저 도우미 부서
원래 상태 알프레드 (주) 마리아 영업
User1 알프레드 마케팅
User2 마리아 서비스

이와 같은 충돌을 다양한 방법으로 해결할 수 있습니다. 자세한 내용은 방법: 변경 충돌 관리참조하세요.

충돌 감지 및 해결 검사 목록

모든 수준의 세부 정보에서 충돌을 감지하고 해결할 수 있습니다. 한 가지 극단적인 경우 추가 고려 없이 세 가지 방법(참조 RefreshMode) 중 하나로 모든 충돌을 해결할 수 있습니다. 다른 쪽에서는 충돌하는 모든 멤버의 각 충돌 유형에 대해 특정 작업을 지정할 수 있습니다.

충돌 검색 및 해결을 지원하는 LINQ to SQL 형식

LINQ to SQL에서 낙관적 동시성에서 충돌 해결을 지원하는 클래스 및 기능에는 다음이 포함됩니다.

참고하십시오