낙관적 동시성 제어

Optimistic concurrency control

Optimistic Concurrency Control(OCC; 옵티멀 동시성 제어)는 Optimistic Locking이라고도 하며 릴레이셔널 데이터베이스 관리 시스템 및 소프트웨어 트랜잭션메모리 등의 트랜잭션시스템에 적용되는 동시성 제어 방법입니다.OCC는 여러 트랜잭션이 서로 간섭하지 않고 자주 완료될 수 있다고 가정합니다.트랜잭션 실행 중에는 데이터 리소스에 대한 잠금을 획득하지 않고 데이터 리소스를 사용합니다.커밋하기 전에 각 트랜잭션은 읽은 데이터를 수정한 다른 트랜잭션이 없는지 확인합니다.검사에서 상충되는 수정 사항이 발견되면 커밋 트랜잭션이 롤백되어 다시 [1]시작할 수 있습니다.낙관적 동시성 제어는 H. T. Kung과 John T.[2] Robinson에 의해 처음 제안되었다.

OCC는 일반적으로 데이터 경합이 적은 환경에서 사용됩니다.충돌이 드문 경우, 잠금 관리 비용이나 다른 트랜잭션의 잠금 해제를 기다리지 않고 트랜잭션을 완료할 수 있으므로 다른 동시성 제어 방법보다 처리량이 더 높습니다.그러나 데이터 리소스에 대한 경합이 빈번한 경우 트랜잭션을 반복적으로 재시작하는 비용이 성능에 큰 영향을 미치므로 다른 동시성 제어 방법이 더 적합합니다.그러나 잠금 기반("pessimistic") 방식도 성능이 저하될 수 있습니다. 잠금 방식은 교착 상태가 방지된 경우에도 효과적인 동시성을 크게 제한할 수 있기 때문입니다.

낙관적 동시성 제어 단계

낙관적인 동시성 제어 트랜잭션에는 다음 [2]단계가 포함됩니다.

  • 시작: 트랜잭션 시작을 나타내는 타임스탬프를 기록합니다.
  • 수정: 데이터베이스 값을 읽고 변경 사항을 임시로 기록합니다.
  • 검증:다른 트랜잭션에 이 트랜잭션에서 사용한 데이터(읽기 또는 쓰기)가 수정되었는지 확인하십시오.여기에는 이 트랜잭션의 시작 시간 이후에 완료된 트랜잭션과 선택적으로 유효성 검사 시간에 여전히 활성 상태인 트랜잭션이 포함됩니다.
  • 커밋/롤백:경합이 없는 경우는, 모든 변경을 유효하게 합니다.경합이 있는 경우는, 통상, 트랜잭션을 중단하는 것으로 해결합니다.다만, 다른 해결 스킴도 가능합니다.특히 이 단계와 이전 단계가 단일 원자 연산으로 수행되지 않는 경우 사용 시간 버그가 발생하지 않도록 주의해야 합니다.

웹 사용

HTTP의 스테이트리스 특성으로 인해 웹 사용자 인터페이스에서는 잠금을 실행할 수 없습니다.사용자가 레코드 편집을 시작한 후 "취소" 또는 "로그아웃" 링크를 누르지 않고 나가는 것이 일반적입니다.잠금을 사용하는 경우, 동일한 레코드를 편집하려는 다른 사용자는 첫 번째 사용자의 잠금이 시간 초과될 때까지 기다려야 합니다.

HTTP는 내장 OCC 형식을 제공합니다.첫 번째 GET 요구에 대한 응답에는 후속 PUT 요구를 If-Match 헤더로 사용하기 위한 ETAG를 포함할 수 있습니다.If-Match 헤더에 오래된ETAG가 있는 PUT 요구는 [3]거부될 수 있습니다.

일부 데이터베이스 관리 시스템은 특별한 애플리케이션 코드를 필요로 하지 않고 OCC를 기본적으로 제공합니다.또, 데이타베이스 외부에 OCC 레이어를 실장해, 레코드의 대기나 사일런트 덮어쓰기를 회피할 수 있습니다.이러한 경우, 양식은 레코드의 원래 내용, 타임스탬프, 시퀀스 번호 또는 불투명한 토큰이 포함된 숨겨진 필드를 포함할 수 있습니다.송신시에, 이것은 데이타베이스와 비교됩니다.다를 경우 충돌 해결 알고리즘이 호출됩니다.

예

「 」를 참조해 주세요.

레퍼런스

  1. ^ Johnson, Rohit (2003). "Common Data Access Issues". Expert One-on-One J2EE Design and Development. Wrox Press. ISBN 978-0-7645-4385-2. Archived from the original on 8 October 2011.
  2. ^ a b H. T. Kung, J. T. Robinson (1981). "On Optimistic Methods for Concurrency Control" (PDF). ACM Transactions on Database Systems. Archived (PDF) from the original on August 31, 2019.
  3. ^ "Editing the Web - Detecting the Lost Update Problem Using Unreserved Checkout". W3C Note. 10 May 1999.
  4. ^ 도움말: 편집 경합
  5. ^ "Bugzilla: FAQ: Administrative Questions". MozillaWiki. 11 April 2012.
  6. ^ "Module ActiveRecord::Locking". Rails Framework Documentation.
  7. ^ "Object Relational Mapping (GORM)". Grails Framework Documentation. Archived from the original on 2014-08-15.
  8. ^ "Transaction Processing". GT.M Programmers Guide UNIX Edition.
  9. ^ "Tip 19 – How to use Optimistic Concurrency with the Entity Framework". MSDN Blogs. 19 May 2009.
  10. ^ "Transaction Concurrency - Optimistic Concurrency Control". Mimer Developers - Features. 26 February 2010. Archived from the original on 21 March 2013. Retrieved 6 May 2013.
  11. ^ "The Datastore". What Is Google App Engine?. 27 August 2010.
  12. ^ "Updating Parts of Documents". Retrieved 2018-06-28.
  13. ^ "Elasticsearch - Guide - Index API". Elasticsearch Guide. 22 March 2012.
  14. ^ "Couchdb Wiki - Document_revisions". Archived from the original on 4 February 2017.
  15. ^ "Transactions - MonetDB". 16 January 2013.
  16. ^ "Transactions in Redis".
  17. ^ "Working with Items and Attributes - Conditional Writes". Retrieved 2 November 2020.
  18. ^ "API Overview - Resource Operations". Retrieved 3 November 2020.
  19. ^ Yugabyte, Team. "Explicit locking YugabyteDB Docs". docs.yugabyte.com. Retrieved 2022-01-04.

외부 링크