Contact 1997

개요

대용량서비스를 하면 동시성 처리에 대한 고민을 많이 하게 된다. 동시에 들어오는 요청에 대해서 누락없이 제대로 반영이 되는가에 대한 내용들.

비슷한 글들이 많아서 나 또한 그런 글을 쓸 필요는 없을 것 같고, 단지 mysql 공홈에 있는 Locking Reads 내용을 읽어보고, InnoDB engine 에서 제공하는 락인 Shared Lock 과 Exclusive Lock 을 이해하는 시간을 개인적으로 가졌다. 그리고 애플리케이션단에서 어떻게 적용할지에 대한 코드도 작성했다. (사실 이 내용도 블로그에 무수히 많지만 내 개념정리차 작성한다.)

공홈의 내용은 구글번역기에 도움을 얻었다. (+ 의역)

Locking Reads (읽기잠금)

저장이나 수정에 대한 트랜잭션 수행 시, 일반적인 조회 구문은 보호받을 수 없다. 타 트랜잭션이 만약 특정 로우에 대해서 수정/저장을 수행할 수 있기 때문이다. InnoDB 는 해당 사항에 대한 보호장치를 위해 두 가지 타입의 Locking Reads 를 제공하고 있다. 추가로 Locking Reads 를 이용할때는 autocommit 이 disabled 로 처리되어있어야 한다. (autocommit = 0)

SELECT ... FOR SHARE : Shared Lock (S-Lock : 공유잠금)

읽을만한 특정 로우에 대해서 shared mode lock 을 세팅할 수 있다. 다른 세션도 해당 로우를 읽을 수 있다. 그러나 먼저 읽은 transaction 이 commit 하기 이전에 다른 세션에서 해당 로우의 데이터를 update 할 수 없다. 다른 세션의 변경쿼리는 기존의 transaction 이 commit 을 수행하기 이전까지 계속 기다리다가 commit 이 되면 그제서야 update 쿼리가 수행된다. SELECT ... FOR SHARE 로 특정로우에 락이 걸려있더라도 타 트랜잭션도 그 로우에 락을 걸 수 있다.

SELECT ... FOR UPDATE : Exclusive Lock (X-Lock : 배타잠금)

특정 로우에 update 문을 실행한것처럼 lock 이 세팅된다. 다른 transaction 은 해당 로우를 업데이트할 수 없이 blocked 이 된다. 다른 transaction 이 SELECT ... FOM SHARE 를 하더라도 blocked 된다. X-Lock 이 걸리면 타 트랜잭션은 락을 걸 수 없다.

S-Lock & X-Lock 다이어그램

실제 터미널을 2개정도 띄어놓고, 쿼리날리면서 테스트해본 결과를 다이어그램으로 옮겨봤다.

그래서..?

단순 동시에 읽는 횟수가 많다면, SELECT ... FOR SHARE 를 해도 상관없다.

하지만 동시읽기횟수 < 동시쓰기횟수인 경우에는 SELECT ... FROM UPDATE 로 배타잠금을 걸어둬야한다.

애플리케이션 레벨단 코드

@Transactional
fun addItemByInventoryIdWithPsRead(id: Long): Inventory {
	// s-lock
    // 동시에 요청 오게된다면, 데드락이 발생했다면서 요청이 실패한다.
    val inventory = entityManager.find(InventoryV3::class.java, id, LockModeType.PESSIMISTIC_READ)
        ?: throw RuntimeException("인벤토리 미확인 : $id")

    inventory.addItemIfPossibleOrThrow()
    return inventory
}

@Transactional
fun addItemByInventoryIdWithPsWrite(id: Long): Inventory {
    // x-lock timeout 설정
    // 동시에 요청이 올 때 데드락을 방지하기 위해 타임아웃을 걸어둔다.
    // 만약 타임아웃을 넘어가면 'LockTimeoutException' 이 발생한다.
    val properties: Map<String, Any> = mutableMapOf<String, Long>().apply {
        this["javax.persistence.lock.timeout"] = 1000L
    }
    val inventory = entityManager.find(Inventory::class.java, id, LockModeType.PESSIMISTIC_WRITE, properties)
        ?: throw RuntimeException("인벤토리 미확인 : $id")

    inventory.addItemIfPossibleOrThrow()
    return inventory
}

(수정 : 2022-11-12)

MySQL & JPA 로는 배타잠금에서 javax.persisntence.lock.timeout 이 지원되지 않는다. lock.timeout 대신에 javax.persistence.query.timeout 을 쓰는 걸 고려한다. lock.timeout 을 쓰고자 한다면, 코드레벨에서 별도 mysql 단으로 native query 를 개별 트랜잭션마다 쿼리 호출전에 날려주어야 한다.

(https://github.com/andistoev/testing-pessimistic-locking-handling-spring-boot-jpa-mysql/blob/master/src/main/java/com/andistoev/psmlockingservice/CustomizedItemRepositoryImpl.java)

참고

https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html

https://dev.mysql.com/doc/refman/8.0/en/innodb-deadlock-example.html