Named Lock3 [Spring & DB] 기존 Named Lock 방식 개선하기 들어가며이전에 Named-Lock 을 통해 동시성을 제어하는 방식과 분산락을 이용하여 제어하는 방식을 비교하며, Named-Lock은 경쟁 상태에 들어가는 요청이 늘어나는 경우에, ConnectionPool 이 고갈되는 현상이 생길 가능성이 존재한다며 단점으로 언급하였었습니다.그 이유로는 이전 글에서 언급하였던 것처럼 락을 획득하고 제어하는 트랜잭션 내에서 또 다른 트랜잭션이 필요하였기 때문입니다. 이러한 생각과 함께 또 다른 생각은 그렇다면 락을 획득하고 제어하는 부분에서는 트랜잭션을 걸지 않고 처리하면 되는 것이 아닐까? 라는 생각이 들었습니다. 하지만 Named Lock 을 해제하기 위해선 획득한 세션과 동일한 세션이 필요하며, 이를 유지하는 방법으로 트랜잭션을 묶어 동일한 커넥션을 가져오도록 강제.. 2025. 7. 6. [DB] MySQL NamedLock vs Redisson 락 관리. 들어가며이전 글(https://kongdevlog.tistory.com/20)에서 Named Lock을 통해 삽입 작업에서의 동시성을 제어하였습니다.다만 이 과정에서, Redisson을 사용하는 방법이 더 좋은 방법이라고 생각이 들어 이를 비교해보고자 글을 작성하게 되었습니다.테스트 설계동시성이 발생할 수 있는 상황을 발생시키기 위해 다음과 같은 API 시나리오를 작성하였습니다.특정 엔티티(행) 조회.해당 엔티티의 컬럼 값 증가.증가한 컬럼 값 반환.이 과정에서 조회 후, 값을 증가하는 트랜잭션이 동시성이 발생할 수 있는 상황입니다.Test Entity@Entitypublic class TestEntity { @Id @GeneratedValue(strategy = GenerationType.I.. 2025. 2. 25. [DB & 팀프로젝트] 삽입 작업에서는 어떻게 동시성 제어를 할까? 들어가며이전 글(https://kongdevlog.tistory.com/19)에서는 행 단위 잠금만으로 모든 동시성 문제를 해결할 수 있을 것 같다고 생각을 하였습니다. 하지만 이번 기능을 구현하며, 잘못된 생각이었다는 것을 깨닫게 되었습니다. 문제 상황사용자 A가 다른 사용자 B에게 매칭을 요청하는 기능을 맡아 구현하게 되었습니다. 따라서 저는 아래와 같은 플로우로 코드를 구현하게 되었습니다. 1. A.id 와 B.id 둘 사이의 진행중인 매칭이 존재하는지 확인. 2 - 1. 매칭이 존재한다면 예외를 반환 2 - 2. 매칭이 존재하지 않다면, 매칭 생성. 이 과정을 단순히 하나의 트랜잭션으로 구현하였습니다.@Transactionalpublic void request(Long requesterId, Lo.. 2025. 2. 18. 이전 1 다음
