트랜잭션과 트랜잭션 격리수준

트랜잭션

DBMS를 이용하는 WAS 환경에서 트랜잭션 설정은 보통 DAO에서 직접 정하지 않고, 비지니스로직이 들어간 서비스 계층에서 정하기 마련이다. 이 부분을 곱씹어보면 트랜잭션을 좀 더 가슴으로 느낄 수 있다. 트랜잭션은 한 비지니스로직과 DBMS가 소통하는 논리적 단위이다. 같은 트랜잭션 내에서 모든 변경사항은 그 생명주기를 같이 하게 된다.

 

 

트랜잭션 격리수준

트랜잭션 격리수준은 여러 트랜잭션의 동시성과 관련된 개념이다. 이를테면 A 트랜잭션에서 변경하고 있는 레코드를 B트랜잭션이 읽어올 수 있을지에 대한 내용이다.

 

 

READ_UNCOMMITTED

READ_UNCOMMITTED 격리수준에서는 아무런 RACE CONDITION을 고려하지 않는다. 즉, 한 트랜잭션이 특정 레코드에서 어떤 작업을 하든 다른 트랜잭션은 이 레코드에 접근할 수 있는 것이다. 이는 멀티태스킹 환경에서 동일한 매커니즘을 보장하지 못하므로 실제 DBMS는 이 격리수준을 사용하지 않는다. 다만, 특정 데이터가 READ_ONLY인 경우에는 동시성을 제어하는 오버헤드 비용을 줄여 높은 성능을 제공한다.(크롤링 API에 제격일듯?)

 

READ_COMMITTED

READ_COMMITTED 격리수준에서는 트랜잭션이 커밋 또는 롤백될 때까지 작업하는 레코드에 대한 쓰기락을 얻는다. 이때 락이 걸린 레코드를 접근하는 트랜잭션은 락을 얻을 때까지 대기하게 된다. 락을 이용해 트랜잭션의 정합성을 보장한 것처럼 보이지만 NON-REPEATABLE READ문제를 고려해야 한다.

그림에서 보면 TRANSACTION B가 최초 실행한 SELECT * ID 7884 결과는 1이다. 이때 B의 실행이 끝나기 이전에 TRANSACTION A가 레코드 ID를 1010으로 바꿨다고 하자. 이후 B의 동일한 쿼리인 SELECT * ID 7884는 0의 결과를 반환할 것이다.

 

 

REPEATABLE READ

REPEATABLE READ 격리 수준에서는 NON-REPEATABLE READ문제를 해결한다. InnoDB에서 UNDO로그를 이용해 이 격리 수준을 지원하는 건 동일한데 실제 구현에서는 트랜잭션에 넘버링을 했다. 즉, SELECT 작업을 수행할 때 UNDO로그를 참고하는 기준은 락을 얻을 수 있는지가 아닌, 트랜잭션 번호를 참고하는 것이다. 만약 최초 수행한 SELECT의 레코드 트랜잭션 넘버와 이후 수행한 SELECT의 레코드의 트랜잭션 넘버가 다르다면 변경이 일어난 것으로 생각하고 UNDO로그를 참고해 결과를 리턴하는 것이다.

 

 

SERIALIZABLE

SERIALIZABLE 격리 수준은 가장 동시성에 엄격한 격리 수준이다. 한 트랜잭션이 접근한 모든 레코드는 트랜잭션 커밋 시점까지 아무도 작업할 수 없다. 데이터 관리는 수월하지만 성능 상 단점이 많다.

 

 

InnoDB 쿼리 별 LOCK 수준

배타적 잠금과 공유잠금

배타적 잠금은 트랜잭션에서 레코드에 변경을 수행할 때 획득하는 잠금이고 공유잠금은 해당 레코드를 읽을 때 그 레코드를 변경하지 못하게 막는 잠금이다.

SELECT

기본적으로 SELECT쿼리에서는 아무런 락을 걸지 않는다. 만약 SELECT하는 레코드가 쓰기락을 건 상태여도 UNDO로그를 이용해 대기없이 원하는 결과를 읽어낼 수 있다.

 

UPDATE DELETE INSERT

변경을 주는 작업이므로 변경할 대상을 찾기 위해 인덱스 테이블을 스캔할 때 스캔 대상에 전부 락을 건다. 논리적으로 맞는 방법이다. 인덱스를 스캔하는 중 데이터의 변경이 생기면 항상 동일한 결과를 보장하지 못한다. 결국 인덱스를 잘 이용해 스캔의 범위를 좁히는 건 서칭 시간의 성능에도 중요하지만 동시성을 높여 성능을 개선하는 작업에서도 매우 중요하다.