테이블 잠금과 관련된 트랜잭션 분리 수준

테이블 잠금과 관련된 트랜잭션 분리 수준

약 4가지 수준의 격리 상태를 읽었습니다.

Isolation Level       Dirty Read    Nonrepeatable Read  Phantom Read  
READ UNCOMMITTED      Permitted       Permitted           Permitted
READ COMMITTED              --        Permitted           Permitted
REPEATABLE READ             --             --             Permitted
SERIALIZABLE                --             --              --

각 트랜잭션 분리가 테이블에서 수행하는 잠금을 이해하고 싶다.

READ UNCOMMITTED - no lock on table
READ COMMITTED - lock on committed data
REPEATABLE READ - lock on block of sql(which is selected by using select query)
SERIALIZABLE - lock on full table(on which Select query is fired)

격리에서 할 수 세 을 다음에 .
더티 판독 - 잠금 없음
반복할 수 없는 읽기 - 커밋된 데이터에 잠금으로 더러운 읽기 없음
팬텀 읽기 - select 쿼리를 사용하여 선택되는 sql 블록에 잠금

이러한 분리 레벨을 정의하는 위치를 이해하고 싶다.jdbc/hibernate 레벨만 또는 DB도 마찬가지입니다.

추신: 오라클 격리 레벨의 링크를 확인했지만, 서툴러 보여서 데이터베이스 고유의 링크에 대해 이야기하고 있습니다.

각 트랜잭션 분리가 테이블에서 수행하는 잠금을 이해하고 싶다.

예를 들어, 3개의 동시 프로세스 A, B 및 C가 있다고 가정합니다.A에서는 트랜잭션 시작, 데이터 쓰기 및 커밋/롤백(결과에 따라 다름)이 이루어집니다.는 BA를 됩니다.SELECT스테이트먼트를 사용하여 데이터를 읽습니다.C 이 c c c c c c c c c c c c c은 동일한 T에서 합니다.

• 커밋되지 않음 확인 - 테이블에 잠금이 걸려 있지 않음.표에 데이터를 쓰면서 읽을 수 있습니다.즉, A는 데이터를 쓰고(미커밋), B는 이 미커밋 데이터를 읽고(어떤 목적으로도) 사용할 수 있습니다.A가 롤백을 실행해도 B는 여전히 데이터를 읽고 사용하고 있습니다.이는 물리적으로 관련이 없는 테이블(예, 실제 애플리케이션 =\)에 데이터 홀이 발생할 수 있으므로 가장 빠르지만 가장 안전하지 않은 데이터 작업 방법입니다.
• COMMITED(커밋 완료) - 커밋된 데이터를 잠급니다.커밋된 데이터만 읽을 수 있습니다.즉, A는 데이터를 쓰고, B는 A가 커밋을 실행할 때까지 A가 저장한 데이터를 읽을 수 없습니다.여기서의 문제는 C가 B클라이언트에서 읽고 사용한 데이터를 갱신할 수 있고 B클라이언트에서는 갱신된 데이터가 없다는 것입니다.
• Repeatable READ - SQL 블록에서 잠급니다(선택 쿼리를 사용하여 선택).즉, B는 어떤 조건, 즉 데이터를 읽습니다. WHERE aField > 10 AND aField < 20는 , 에 데이터를 삽입합니다.aField값은 10에서 20 사이이고 B는 데이터를 다시 읽고 다른 결과를 얻습니다.
• 시리얼 가능 - 전체 테이블에서 잠급니다(Select 쿼리가 실행됨).즉, B는 데이터를 읽고 다른 트랜잭션은 테이블의 데이터를 수정할 수 없습니다.이것이 가장 안전하지만 가장 느린 데이터 작업 방법입니다.또한 단순한 읽기 조작으로 테이블이 잠기므로 생산 시 큰 문제가 발생할 수 있습니다.T 테이블이 청구서 테이블이라고 가정하면 사용자 X가 그날의 청구서를 알고 사용자 Y가 새로운 청구서를 작성하려고 합니다.그러므로 X가 청구서 읽기를 실행하는 동안 Y는 새로운 청구서를 추가할 수 없습니다(또한 비용이 많이 드는 경우에는 실제로 사람들이 청구서를 작성해야 합니다).d, 특히 보스).

JDBC/hibernate 레벨만 또는 DB에서도 이러한 분리 레벨을 정의하고 있는 위치를 알고 싶다.

JDBC를 사용하여 정의합니다.

휴지 상태 사용:

<property name="hibernate.connection.isolation">2</property>

어디에

• 1: 커밋되지 않은 읽기
• 2: 읽기 커밋
• 4: 반복 가능한 읽기
• 8: 시리얼라이저BLE

휴지 상태 설정은 여기서 가져옵니다(죄송합니다.스페인어입니다).

덧붙여서, RDBMS 에서도 분리 레벨을 설정할 수 있습니다.

• MySQL 분리 수준,
• SQL Server 분리 수준
• Informix 격리 수준(개인 메모:절대 잊지 않을게요SET ISOLATION TO DIRTY READ□□□□□□□□★

그리고 또...

brb tea가 말했듯이 데이터베이스 구현 및 MVCC 또는 2상 잠금 알고리즘에 따라 달라집니다.

CUBRID(오픈소스 RDBMS)는 다음 2가지 알고리즘의 개념을 설명합니다.

• 2상 잠금(2PL)

첫 번째는 T2 트랜잭션이 A 레코드를 변경하려고 할 때 T1 트랜잭션이 이미 A 레코드를 변경했음을 인식하고 T1 트랜잭션이 완료될 때까지 기다립니다.T2 트랜잭션은 T1 트랜잭션이 커밋되는지 롤백되는지 알 수 없기 때문입니다.이 방법을 2상 잠금(2PL)이라고 합니다.

• Multi-Version Concurrency Control(Multi-version 동시제어)

다른 하나는 T1 트랜잭션과 T2 트랜잭션 각각이 변경된 버전을 가질 수 있도록 하는 것입니다.T1 트랜잭션이 A 레코드를 1에서 2로 변경해도 T1 트랜잭션은 원래 값 1을 그대로 두고 A 레코드의 T1 트랜잭션 버전을 2로 쓴다.그런 다음 다음 T2 트랜잭션은 A 레코드를 2에서4가 아닌 1에서3으로 변경하고 A 레코드의 T2 트랜잭션버전을 3으로 씁니다.

T1 트랜잭션이 롤백될 때 T1 트랜잭션버전인2가 A레코드에 적용되지 않아도 상관없습니다.그 후 T2 트랜잭션이 커밋되면 T2 트랜잭션 버전인 3이 A 레코드에 적용됩니다.T2 트랜잭션 전에 T1 트랜잭션이 커밋되면 A레코드는 2로, T2 트랜잭션을 커밋할 때는 3으로 변경된다.최종 데이터베이스 상태는 다른 트랜잭션에 영향을 주지 않고 각 트랜잭션을 독립적으로 실행하는 상태와 동일합니다.따라서 ACID 특성을 만족시킵니다.이 방법을 Multi-version Concurrency Control(MVCC; 다중 버전 동시 제어)이라고 합니다.

MVCC를 사용하면 메모리 내의 오버헤드가 증가하고(동일한 데이터의 다른 버전을 유지해야 하므로), 계산(REPETABLE_READ 레벨에서는 업데이트를 해제할 수 없으므로 Optimistick Locking에서 Hiberate와 같이 데이터 버전을 확인해야 합니다)을 동시에 변경할 수 있습니다.

2PL에서는 트랜잭션 분리 수준이 다음을 제어합니다.

• 데이터를 읽을 때 잠금이 실행되는지 여부 및 요청된 잠금 유형입니다.

• 읽기 잠금을 유지하는 기간입니다.

• 다른 트랜잭션에 의해 수정된 행을 참조하는 읽기 작업 여부:

  • 행의 배타적 잠금이 해제될 때까지 차단합니다.

  • 스테이트먼트 또는 트랜잭션을 시작할 때 존재했던 행의 커밋 버전을 검색합니다.

  • 커밋되지 않은 데이터 수정을 읽습니다.

트랜잭션 분리 수준을 선택해도 데이터 수정을 보호하기 위해 획득한 잠금에는 영향을 주지 않습니다.트랜잭션은 항상 수정하는 데이터에 대해 배타적 잠금을 획득하고 해당 트랜잭션에 대해 설정된 분리 수준에 관계없이 트랜잭션이 완료될 때까지 잠금을 유지합니다.읽기 작업의 경우 트랜잭션 분리 수준은 주로 다른 트랜잭션에 의해 수정된 영향으로부터 보호하는 수준을 정의합니다.

분리 수준이 낮을수록 많은 사용자가 동시에 데이터에 액세스할 수 있는 능력은 증가하지만 사용자가 발생할 수 있는 더티 읽기나 업데이트 손실 등 동시성 영향의 수는 증가합니다.

SQL Server에서의 잠금과 격리 수준 간의 관계에 대한 구체적인 예(READ_를 제외한 2PL 사용)읽기_와 함께 커밋됨COMMITED_SNAPSHOT=ON)

• READ_UNCOMMITED: 다른 트랜잭션이 현재 트랜잭션에서 읽은 데이터를 수정하지 못하도록 공유 잠금을 발행하지 마십시오.또한 현재 트랜잭션이 수정되었지만 다른 트랜잭션에 의해 커밋되지 않은 행을 읽을 수 없도록 하는 배타적 잠금으로 인해 UNCOMMITED 트랜잭션이 차단되지 않습니다. [...

• 읽기_커밋됨:

  • 읽기_인 경우COMMITED_SNAPSHOT는 OFF(기본값): 공유 잠금을 사용하여 현재 트랜잭션이 읽기 작업을 실행하는 동안 다른 트랜잭션이 행을 수정하지 않도록 합니다.또한 공유 잠금은 다른 트랜잭션이 완료될 때까지 문이 다른 트랜잭션에 의해 수정된 행을 읽지 못하도록 차단합니다. [...] 행 잠금은 다음 행이 처리되기 전에 해제됩니다. [...]
  • 읽기_인 경우COMMITED_SNAPSHOT는 ON으로 설정되어 있으며, Database Engine은 행 버전 관리를 사용하여 각 스테이트먼트에 스테이트먼트의 선두와 같이 트랜잭션으로 일관된 데이터의 스냅샷을 표시합니다.잠금은 다른 트랜잭션의 업데이트로부터 데이터를 보호하는 데 사용되지 않습니다.

• REPETABLE_READ: 공유 잠금은 트랜잭션의 각 스테이트먼트에서 읽은 모든 데이터에 배치되며 트랜잭션이 완료될 때까지 유지됩니다.

• 직렬화 가능: 범위 잠금은 트랜잭션에서 실행되는 각 문장의 검색 조건과 일치하는 키 값의 범위에 배치됩니다. [...] 범위 잠금은 트랜잭션이 완료될 때까지 유지됩니다.

잠금은 항상 DB 수준에서 수행됩니다.-

Oracle 공식 문서:- 트랜잭션 중 충돌을 방지하기 위해 DBMS는 트랜잭션에 의해 액세스되는 데이터에 대한 다른 사용자의 액세스를 차단하는 메커니즘인 잠금을 사용합니다.(각 스테이트먼트가 트랜잭션인 자동 커밋모드에서는 1개의 스테이트먼트에 대해서만 잠금이 유지됩니다).잠금이 설정된 후에는 트랜잭션이 커밋되거나 롤백될 때까지 잠금이 유효합니다.예를 들어, DBMS는 갱신이 커밋될 때까지 테이블의 행을 잠글 수 있습니다.이 잠금의 효과는 사용자가 더티 판독을 받지 않도록 하는 것입니다. 즉, 값이 영구화되기 전에 값을 읽는 것입니다(커밋되지 않은 갱신된 값에 액세스하는 것은 더티 판독으로 간주됩니다.이는 값이 이전 값으로 롤백될 수 있기 때문입니다.나중에 롤백된 값을 읽으면 유효하지 않은 값을 읽게 됩니다.)

잠금 설정 방법은 트랜잭션 분리 수준이라고 불리는 수준에 따라 결정됩니다. 트랜잭션 분리 수준은 트랜잭션을 전혀 지원하지 않는 것부터 매우 엄격한 액세스 규칙을 적용하는 트랜잭션을 지원하는 것까지 다양합니다.

트랜잭션 분리 수준의 예로는 TRANSACTION_READ_COMMITITED가 있습니다.이 예에서는 커밋될 때까지 값에 액세스할 수 없습니다.즉, 트랜잭션 분리 레벨을 TRANSACTION_READ_COMMITITED로 설정하면 DBMS는 더티 읽기를 허용하지 않습니다.인터페이스 Connection에는 JDBC에서 사용할 수 있는 트랜잭션 분리 수준을 나타내는5개의 값이 포함되어 있습니다.

언급URL : https://stackoverflow.com/questions/16162357/transaction-isolation-levels-relation-with-locks-on-table