Propagation.REQUIRES_NEW란?REQUIRES_NEW는 Spring의 트랜잭션 전파 속성 중 하나로, 독립적인 새로운 트랜잭션을 시작할 때 사용한다.현재 트랜잭션이 존재하든 말든, 무조건 새로운 트랜잭션을 시작한다.기존 트랜잭션이 존재할 경우 잠시 중단되고, 새로운 트랜잭션이 완전히 별도로 실행된다.사용 시기로깅, 알림, 감사 로그 등 독립적 저장이 필요한 작업부모 트랜잭션의 롤백 여부와 상관 없이 저장되어야 하는 작업을 할 때 사용한다.트랜잭션 범위 최소화락 범위나 예외 영향을 줄이고 싶을 때 사용한다.경우에 따른 롤백하위 메소드에서 예외 발생아래 예제를 보면 상위 메소드의 결과까지 롤백이 된 것을 볼 수 있다.분명 REQUIRES_NEW를 사용하면 독립적인 트랜잭션이라 했는데 왜 이런..
분류 전체보기
MySQL Named 락이란?MySQL에서 제공하는 이름 기반의 사용자 락이다.동시성 제어를 위해 DB 안에서 간단히 분산락처럼 사용할 수 있는 기능이다.주요 함수GET_LOCK(name, timeout)입력 받은 name으로 timeout 초 동안 잠금 획득을 시도한다.timeout에 음수를 입력하면 잠금을 획득할 때까지 무한대로 대기한다.한 세션에서 잠금을 유지하고 있는 동안 다른 세션에서 동일한 이름의 잠금 획득이 불가능하다.GET_LOCK()을 이용하여 획득한 잠금은 트랜잭션이 커밋/롤백 되어도 풀리지 않는다.즉, 락을 잡은 커넥션에서 직접 해제하거나 DB 커넥션이 종료되어야 락이 풀린다.RELEASE_LOCK(name)입력 받은 name의 잠금을 해제한다.RELEASE_ALL_LOCKS()현재 ..
비관적 락이란?"언제들 충돌 날 수 있어!" 라고 비관적으로 가정하고 미리 락을 걸어 다른 트랜잭션이 못 건드리게 막는 방식이다.작동 방식데이터를 조회할 때부터 DB에 락을 걸어버린다. 읽거나 쓰는 동안 다른 트랜잭션은 이 데이터에 접근이 불가능하다. (대기하거나 실패한다.)장점충돌 방지가 확실데이터를 조회하는 순간부터 락을 걸기 때문에 다른 트랜잭션이 접근할 수 없다. 그러므로 정합성 보장이 중요한 재고 감소, 은행 이제, 예약 시스템 등에 적합하다.복잡한 충돌 처리 로직이 필요 없음낙관적 락처럼 버전 비교 후 실패 시 재시도 등의 코드를 작성할 필요가 없다.단점성능 저하 가능성비관적 락은 락이 걸려 있는 동안 다른 트랜잭션이 대기해야 하므로 동시성이 저하될 수 있다.다만, 데이터의 정합성과 시스템의 ..
낙관적 락이란?"충돌은 잘 안 날거야" 라고 낙관적으로 가정하고 실제로 충돌이 발생하면 그때 처리하는 동시성 제어 방식을 말한다.작동 방식데이터를 읽을 때 버전 번호(@Version)를 함께 읽음데이터를 수정한 뒤, 업데이트 시점에 버전 번호를 비교DB에 있는 버전 번호랑 다르면 실패(다른 누군가가 먼저 수정했음을 의미)충돌 시ObjectOptimisticLockingFailureException 예외가 발생한다.재시도하거나 사용자에게 충돌 메시지를 보여주는 등 예외 처리가 필요하다.장점성능적으로 유리DB에 직접 락을 걸지 않기 때문에 비관적 락보다 성능상 이점이 존재한다.데드락 X마찬가지로 DB에 직접 락을 걸지 않기 때문에 데드락이 발생하지 않는다.분산 환경에 적용 가능JVM 수준이 아닌 DB 수준에..
동시성 제어란?여러 프로세스나 스레드가 동시에 같은 자원(데이터나 상태)에 접근할 때, 무결성과 일관성을 보장하기 위한 기법왜 필요할까?동시에 여러 사용자가 같은 데이터를 수정하면 문제가 발생할 수 있다.아래 재고 감소 예시를 통해 살펴볼 수 있다. 사용자 A가 상품을 구매하려고 조회하니 1개의 재고가 남아 있다.동시에 사용자 B가 조회하니 1개의 재고가 남아 있다.사용자 A는 구매 가능 상태이므로 물품을 구매하고 재고를 0으로 업데이트한다.사용자 B 또한 구매 가능 상태이므로 물품을 구매한다.Synchronized란?synchronized는 JVM 수준에서 제공되는 모니터 락(Monitor Lock)을 기반으로 작동한다.Monitor란?모든 객체(Object)는 모니터를 가지고 있음synchronize..
개요이번 글에서는 10,000명이 동시에 WebSocket 서버에 접속하는 부하 테스트를 진행하면서 발견한 문제점과 이를 개선한 과정에 대해 정리해보겠다. 이번 부하 테스트의 목적은 10,000명의 사용자가 동시에 WebSocket 및 STOMP 프로토콜을 통해 서버에 연결한 후, 해당 연결이 안정적으로 유지되는지를 확인하는 것이다.부하 테스트 클라이언트는 Go 언어를 이용해 구현했으며, 모니터링 도구로는 Prometheus와 Grafana를 이용했다.OOM 발생단일 WAS(2Core, 2GB) 환경에서 부하 테스트를 진행하니 OutOfMemeryError가 발생했다. OOM이 발생한 직후 Heap Dump를 떠 파일을 분석해보았다. 분석 도구로는 Memory Analyzer(MAT)를 사용했다.분석 결..
