[JPA] 동시성 처리 - 비관적 락 VS 낙관적 락

이슈 상황

진행하고 있는 프로젝트에 '끝말잇기' 기능을 제공중이다.

예외처리가 적용되지 않고 두개의 단어가 동시에 삽입되었다! 

 

문제 해결 과정

우선 Chatgpt를 이용해서 해당 사항에 대해 물어보았다.

 

1. 격리수준 설정을 고려 -> 탈락

우선 PostgreSQL에서는 4가지의 Transaction 격리 수준을 설정할 수 있다.

끝말잇기에 적용하는 것을 생각해봤을때, 하나의 transaction에서 데이터를 읽을때, 다른 transaction에서 커밋되지 않은 데이터도 읽어야함. 

Postgresql은 Read Uncommited를 지원하지 않는다고 한다! 결론적으로 DirtyRead가 불가능하다. 

 

2. 낙관적 락과 비관적 락 고려하기 (오 괜찮다!)

낙관적락과 비관적락을 사용하는 기준은 "동시에 수정을 하는일이 빈번하게 일어나는가 ?"

비관적 락(Pessimistic Lock)

따라서 하나의 트랜잭션이 데이터를 읽는 시점에서 락(Lock)을 걸고, 조회 또는 갱신 처리가 완료될 때까지 유지합니다. SELECT...FOR UPDATE로 조회된 해당 로우는 잠금을 획득하여 해당 트랜잭션이 끝나기 전까지 다른 트랜잭션이 접근하지 못하고 대기해야 합니다. 대기 시간을 줄 수 있다.

공유 자원을 사용할 때 다른 쓰레드와 충돌이 발생할 가능성이 높다고 가정하고 그에 따라 공유 자원에 대한 락을 걸어 다른 쓰레드에 대한 접근을 막는 방식입니다. 따라서, 충돌이 빈번하게 일어나는 환경에서 사용하게 되면 효과적일 수 있습니다.

 

낙관적 락(Optimistic Lock)

충돌이 발생하지 않을 것으로 가정하고 그에 따라 공유 자원에 대한 락을 걸지 않고 접근할 수 있습니다. 만약, 다른 쓰레드가 이미 락을 걸어놓은 경우에는 대기하다가 락이 풀리면 자원에 대한 접근을 시도합니다.

 

 

실무에서 구체적인 예시를 들면, 낙관적 락은 일반적으로 읽기 비율이 높은 경우에 사용할 수 있습니다. 예를 들어, 게시글을 읽는 쓰레드가 다수 존재하고, 쓰기 작업은 비교적 드물게 발생하는 경우에는 낙관적 락이 효과적일 수 있습니다. 반면에, 쓰기 작업이 빈번하게 발생하는 경우에는 비관적 락을 사용하는 것이 좋습니다.

3. 분산 락 사용 -> 탈락

분산시스템에서 여러 서버간에 공유자원에 대한 동시 접근을 제어하기 위해 분산 락을 사용할 수 있다고 한다. 

나의 프로젝트는 분산시스템이 아니고 단일 서버이기에 탈락.

 

4. 캐시 사용 -> 보류

캐시를 활용해서 중복단어를 체크하는 방법을 고려해볼 수 있겠다. DB조회를 줄이고, 성능을 향상시키는 방법.

HashMap 또는 Redis와 같은 외부 캐시를 이용하는것을 고려해볼 수 있겠다. 실제 프로덕션 환경이기에 Redis와 같은 외부 캐시를 사용하는 것이 더 적합하다고 고려됨. 캐시 사용으로 인해서 해결이 될 문제인가?! 아직 잘 모르겠다. 우선 보류

 

락(Locking)을 사용하는 것과 격리 수준(Isolation Level) 설정의 장단점

측면	락(Locking)	격리 수준 설정
제어 정도	높음	낮음
복잡성	높음	낮음
성능 영향	높음 (Lock Contention 가능)	낮음
데이터 일관성 보장	가능	보장 (설정에 따라 다름)
데드락 발생 가능성	높음 (적절한 관리 필요)	낮음 (일반적으로 시스템이 처리)
동시성 제어	개발자가 직접 구현해야 함	데이터베이스 시스템에서 처리
유연성	높음 (프로그래밍 방식으로 사용)	낮음 (일반적으로 설정 변경으로 사용)