Lock에 의한 배타제어에 대해서는 조금더 파내려가보자.
Falcon에서는 InnoDB와 마찬가지로 행레벨 lock을 지원한다.
행레벨 lock기능이 없으면 페이지단위나 테이블단위등 필요이상의 lock을 확보해버리기 때문에 동시 실행성이 크게 떨어지게 된다.
매우 중요하고 기본적인 기능인 것이다.
또, Multi Version Concurrency Control(MVCC)도 채용하고 있다. 이것은 읽어들일 때에 레코드를 lock하는 것이 아니라 커밋된 값을 읽는 것이 가능한 기능으로 읽는 것과 갱신의 경합을 방지할 수 있다.
한편 읽어들 일때에 강제적으로 배타lock을 거는 SELECT FOR UPDATE도 지원되고 있다. (베타판을 예정) 이것도 InnoDB하고 마찬가지이다.
또 트랜잭션 분리레벨은 현재에는 Read Committed와 Repeatable Read를 지원하고 있다.
Serializable은 베타판까지는 지원될 예정이다.
한편 Read Uncommitted는 그 필요성이 낮기 때문에 서포트예정은 없다. 기본적인 트랜잭션분리레벨은 InnoDB하고 마찬가지로 Repeatable Read이다.
InnoDB에서는 Repeatable Read로 한 경우에 동일 트랜잭션내에서의 SELECT문이 항상 같은 결과를 주는 특징이 있지만 (SELECT FOR UPDATE나 SELECT LOCK IN SHARE MODE로 lock을 거는 경우나 자기자신의 트랜잭션내에서 갱신한 정보는 빼고... ) Falcon도 마찬가지이다.
이 때문에 InnoDB에서도 Falcon에서도 동일 트랜잭션내에서의 읽어들인 결과가 다른 트랜잭션의 영향에 따라서 같이 변해버리는 퀀텀리드현상을 막을 수 있게된다.
InnoDB에서는 Repeatable Read와 바이너리로그 특징을 활용해서 Lock을 거의 사용하지 않는 온라인 백업과 rollforward recovery가 되지만 Falcon에서도 이런 기능을 서포트할 예정이다.
그외에 다음과 같은 특징이 있다.
- 일부 RDBMS에서는 행Lock에서 관리하는 레코드수가 많아지면 Lock을 페이지 레벨이나 테이블 레벨로 승격하는 Lock escalation이 수행되는 것도 있지만 이것은 Falcon에서도 InnoDB에서도 발생하지 않는다. Lock escalation은 동시 실행성을 극단적으로 떨어트리는 하나의 원인이 되므로 이것이 발생하지않는 것은 중요하다.
- deadlock의 검사는 자동적으로 수행된다. 이것도 Falcon, InnoDB 모두 같다.
이렇게 보면 트랜잭션제어에 대해서 InnoDB도 Falcon도 완전히 같은 것으로 보여지지만 Falcon 우위적인 차이가 몇개 있으니 다음에 알아보자.
