DBMS에서는 여러 사용자가 동시에 같은 데이터를 조회 or 수정할 수 있다. 이런 경우 신뢰성에 문제가 생길 수 있어서 DBMS는 LOCK을 활용해서 충돌 문제를 예방 또는 해결
트랜잭션 격리수준(Isolation level)
DBMS설정에 따라 6가지 LOCK 관리 방식을 설정가능
별도 설정이 없는 경우 READ COMMITTED 격리 수준이 기본
- READ UNCOMMITTED - A가 트랜잭션 내에서 변경중인 데이터를 B가 조회하면 대기 없이 결과 출력(commit되지 않은 데이터)
- READ COMMITTED (가장 기본 설정) - A가 트랜잭션 내에서 변경중인 데이터를 B가 조회만 해도 대기 현상 발생
- REPEATABLE READ - A가 트랜잭션 내에서 SELECT만 해도 B는 UPDATE, DELETE 작업 시 대기 현상 발생 (INSERT는 대기 없이 가능)
- SERIALZABLE - A가 트랜잭션 내에서 SELECT만 해도 B는 UPDATE, DELETE, INSERT 작업 시 대기 현상 발생 (가장 강력한 격리 수준)
Azure SQL Server
- READ COMMITTED SNAPSHOP - A가 트랜잭션 내에서 변경중인 데이터를 B가 조회하면 변경전 데이터로 대기 없이 조회가능
- SNAPSHOP - A가 트랜잭션 내에서 조회한 데이터는 B에서 변경을 완료해도 A의 트랜잭션 내에서는 처음 조회 그대로 조회(다른 사용자가 이미 변경된 데이터를 다시 변경하는 경우 불일치 오류 발생)
트랜잭션 잠금
1. A의 트랜잭션이 실행되는 중에 B의 트랜잭션을 실행하면 뒤에 실행한 B의 트랜잭션은 락상태가 되어서 대기상태에 머문다.
2. A의 트랜잭션이 COMMIT으로 완료되면 기존 값들이 영구적으로 변경되며 저장 후 B의 트랜잭션은 락이 풀린다.
3. B의 트랜잭션이 COMMIT으로 완료되고 값들이 영구적으로 변경되며 저장.
따라서 트랜잭션은 가급적 짧은 시간에 완료되도록 처리하는 것이 좋다.
간혹 BEGIN으로 트랜잭션을 시작하였으나 COMMIT 또는 ROLLBACK을 하지 않아 무한대기 발생 조심.
1111