너T야? 나 T(story)야….

락 선택 기준표 (한눈에 정리)구분충돌 발생 가능성충돌 시 영향도권장 락 종류예시 거의 없음낮음낮음 락 없음게시판, 댓글 수정 가끔 있음중간중간 낙관적 락문서, 프로필, 게시글 편집 자주 발생높음높음 비관적 락재고, 결제, 송금, 좌석 예매 여러 서버높음높음 분산 락쿠폰, 이벤트, 배치, 예약 작업 미션 크리티컬매우 높음매우 높음 비관적 + 분산 락 조합금전 거래, 회계 정산 시스템이 표를 보면 알 수 있듯이 충돌 가능성과 결과의 심각도가 커질수록“락의 강도”를 점점 높여가는 게 핵심이다. 실무에서 자주 발생하는 문제 ① Deadlock Deadlock이란?두 트랜잭션이 서로가 가진 락을 기다리면서무한 대기 상태에 빠지는 현상.예시 트랜잭션 A트랜잭션 B① row1 잠금① row2 잠금② row2 잠금 ..

비관적 락(Pessimistic Lock)이란?비관적 락은 이름 그대로 **“비관적으로 본다”**는 개념이다.“어차피 동시에 접근할 사람 있을 거야.그러니 내가 수정하는 동안 다른 사람은 아예 접근하지 못하게 막자.”즉,데이터를 읽는 순간 DB 레벨에서 행(row)을 잠그고,트랜잭션이 끝날 때까지 다른 트랜잭션이 접근하지 못하게 하는 방식이다.SQL로는 이렇게 쓴다. SELECT * FROM item WHERE id = 10 FOR UPDATE; 이 쿼리가 실행되면,id=10인 row는 해당 트랜잭션이 끝날 때까지 잠긴다.다른 트랜잭션이 같은 row를 수정하려 하면 대기(block) 하거나 LockTimeoutException이 발생한다.비관적 락이 꼭 필요한 상황1) 재고 차감, 수량 관리동시에 여러 ..

“서버가 여러 대로 나뉘어 있는 분산 환경에서는DB의 비관적 락만으로는 완벽히 동시성을 막을 수 있을까?”불가능하다.그래서 등장하는 개념이 바로 분산 락(Distributed Lock) 이다.왜 분산 락이 필요한가?단일 서버에서는 synchronized, ReentrantLock, FOR UPDATE 같은 락으로 충분하다.하지만 서버가 여러 대면 상황이 달라진다.예를 들어보자 서버 A와 서버 B가 같은 DB를 바라본다.두 서버 모두 동시에 “쿠폰 발급 로직”을 실행한다.서버 A에서는 이미 쿠폰 수량을 줄였는데,서버 B는 DB 락 정보를 모르기 때문에 동시에 줄여버린다.→ 결국 “하나 남은 쿠폰을 두 명이 받는” 결과가 나온다.즉,서버가 여러 대일 경우, 각 서버 간의 동기화 락이 없으면비관적 락도 완벽하..

글쓴이만 수정하는데 굳이 락이 필요할까?일반적인 게시판 구조는 이렇게 되어 있다.게시글을 수정할 수 있는 건 글쓴이 본인뿐이다.다른 사람은 수정 권한이 없다.그럼 자연스럽게 이런 의문이 든다.“동시에 수정하는 사람 자체가 한 명뿐인데, 락이 필요할까?”정답은 이렇다 필수는 아니지만, 낙관적 락(Optimistic Lock)을 걸어두는 건 매우 유용한 안전장치다.거의 성능 저하 없이 데이터 유실을 예방할 수 있다. 실제로 발생할 수 있는 “희귀하지만 짜증나는” 상황글쓴이 1명만 수정할 수 있어도 충돌이 완전히 불가능한 건 아니다.예를 들어보자.사용자가 PC 브라우저에서 수정 페이지를 열어둠.동시에 스마트폰에서도 같은 글을 열고 일부 수정.둘 다 저장 버튼을 눌렀을 때,→ 나중에 저장한 쪽이 앞서 저장한 내..

문제 상황: 동시에 수정하면 어떻게 될까?게시판이나 블로그 서비스에서 이런 상황은 흔하다.A 사용자가 게시글을 수정 중이다.B 사용자가 같은 시점에 그 게시글을 조회하거나, 심지어 수정하려 한다.이때 두 명의 수정이 겹치면 어떤 결과가 되어야 할까?둘 다 수정할 수 있다면, 나중에 저장한 사람이 앞사람의 내용을 덮어쓴다.아니면, “누가 먼저 수정했는지” 감지해서 나중 수정은 막을 수도 있다.이걸 통틀어 동시성 제어(Concurrency Control) 라고 한다. 1. 단순한 방법: “마지막 저장이 이긴다”가장 쉬운 방식은 아무 제어도 하지 않고 마지막 저장이 최종본이 되는 것이다.A가 10시에 수정 → 저장B가 10시 1분에 수정 → 저장→ 결국 B의 내용이 DB에 남는다.이건 구현은 단순하지만,문제는..

Spring Boot에서는 클라이언트로부터 데이터를 전달받을 때 @RequestBody, @RequestParam, @PathVariable 등의 어노테이션을 사용합니다. 그 중에서도 @RequestBody와 @RequestParam은 어떤 것을 써야할지 고민이 됩니다.  둘의 특징을 생각해보고 결정을 해보고자 합니다.  @RequestParam 특징 상세1. 요청 파라미터 (Query Parameter) 수신주로 GET 요청의 ?key=value 형식이나 POST 폼 요청에서 사용됨.내부적으로 HttpServletRequest.getParameter("key")와 유사하게 동작. 2. 폼 전송 (application/x-www-form-urlencoded) 지원 태그에서 submit한 값들을 받을 때 ..

보호되어 있는 글입니다.

보호되어 있는 글입니다.

인가(authorization)특정한 경로에 요청이 오면 Controller 클래스에 도달하기 전 필터에서 Spring Security가 검증을 함 import org.springframework.context.annotation.Bean;import org.springframework.context.annotation.Configuration;import org.springframework.security.config.annotation.web.builders.HttpSecurity;import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;import org.springframework.securit..

DisableEncodeUrlFilter 커스텀 SecurityFilterChain을 생성해도 등록되며 비활성은 아래와 같이 세션 관리 설정을 disable 하면 된다.http .sessionManagement((manage) -> manage.disable()); SecurityContextHolderFilter 필터가 등록되는 목적은 이전 요청을 통해 이미 인증한 사용자 정보를 현재 요청의 SecurityContextHolder의 SecurityContext에 할당하는 역할을 수행하고, 현재 요청이 끝나면 SecurityContext를 초기화 한다. 또 로그인을 할 필요가 없게끔 한다. http .securityContext((context) -> context...