개발이군고구마

Backend Deep Dive Spring + JDBC 트랜잭션의 원리이중 실행 방지까지 ThreadLocal, Connection Pool, @Transactional의 동작 원리를 한 번에 이해하는 가이드 — 주니어 개발자를 위한 실전 해설 Spring Framework JDBC / Connection Pool ThreadLocal JDK 21 Virtual Thread 목차 왜 이 문제를 만났는가 — 이중 실행의 위험 JDBC가 Connection을 관리하는 방법 — ThreadLocal 스레드 풀과 Connection 반납 원리 @Transactional 어노테이션의 실제 동작 DB Lock과 트랜잭션 ..

레거시 코드를 보다 보면 @NoArgsConstructor, @AllArgsConstructor가 아무 생각 없이 붙어 있는 경우를 자주 만난다.@NoArgsConstructor@AllArgsConstructorpublic class Response extends DefaultResponse { ....} 처음엔 “이렇게 쓰라고 있는 거겠지” 하고 넘겼지만, 정말 이 생성자들이 왜 필요한지, 그리고 지금 이 위치에 맞는 설계인지에 대한 의문이 들었다. 1. 레거시 코드의 Lombok 생성자 어노테이션 @NoArgsConstructor@AllArgsConstructor@Getterpublic class SampleResponse { private String name; private int..

Spring을 사용하다 보면 아래와 같은 질문을 자주 갖게 된다. “이 클래스는 언제 로딩되었길래 사용할 수 있는(또는 없는) 걸까?”,“컴포넌트 스캔을 하면 바로 객체가 생성되는 걸까?”"컴포넌트 스캔의 결과 생성된 객체는 어떤 형태로 어디에 저장되는 걸까?" 나 역시 컴포넌트 스캔과 JVM의 클래스 로딩을 같은 흐름으로 이해하고 있었고,이로 인해 클래스가 메모리에 올라가는 시점과 Spring이 빈을 생성하는 시점을 명확히 구분하지 못하고 있었다.이 글에서는 다음 세 가지를 중심으로 정리한다.JVM의 클래스 로딩과 Spring의 컴포넌트 스캔은 어떤 점에서 다른가Spring 컨테이너는 언제 빈을 정의하고 언제 생성하는가JVM에 로딩된 클래스와 Spring 빈은 무엇이 다른가 1. JVM의 클래스 로딩..

Static Inner Class 는 필수였을까? 신규 도입한 클라이언트 툴의 데이터를 받는 모든 프리젠테이션 클래스는 아래와 같이 작성되어있다.하나의 요청 모델 클래스 안에 다수의 static inner class가 정의되어 있었고, 요청/응답 모델과 변환 로직이 한 파일에 밀집된 구조였다.public class DisplayController extends AbstractController { // ❌ 수십 개의 static inner class들... public static class DspTmplatRequest implements ConvertableModel { ... } public static class DspTmplatResponse extends Default..

"매일 아침 9시, 담당자가 직접 엑셀을 켜고 마감 임박한 업체 리스트를 추려 이메일을 보내고 있다면?" Problem 데이터 정합성 문제: 요청 마감 일시가 지난 이벤트의 상태(진행중 -> 마감)를 제때 변경하지 못해 사용자에게 잘못된 정보를 노출하는 경우가 잦음.데이터베이스 비효율: 마감이 지나고 한참 지난(180일 이상) 불필요한 이벤트 데이터가 계속 쌓여 쿼리 성능을 저하시킴휴먼 에러 위험이 높은 수기 알림:이벤트 마감이 하루 남은 입점사에게 담당자가 직접 수기로 이메일을 발송대상자가 많아질수록 누락 가능성이 커졌고, 이는 곧 입점사의 불만(Clam) Solution "어떻게 효율적이고 유연하게 만들 것인가"에 집중 조건부 실행을 위한 JobExecutionDecider 도입ㄴ 1시간마다 도는 ..

Problem 자동로그인 시도시 로그인 ""지연"" 현상 자동로그인을 해놓을 경우 다른 기기에서 로그인을 하더라도 해당 정보 계속해서 유지됨 예를 들어 타 기기에서 의도치 않게 자동로그인이 되면 계속해서 그 정보가 남아 타인이 계정에 계속 접속하는 것이 가능하여 ""보안"" 우려 Cause 자동로그인 토큰 검색을 위해 매번 DB 조회특히, DB 버퍼에 쿼리 캐시가 없다면 디스크 I/O 필요하므로 시간, CPU 비용이 상승하게 되는 것자동로그인 여부 확인 시 따로 ""기기 식별 번호"" 를 검증하는 로직이 없음 REDIS 조회 {완전로그인(KEY) : UTID}DB 조회 : WHERE -> 완전로그인 Solution 1️⃣ REDIS 연동 완전 로그인 토큰을 key 값으로 데이터 insert 만료시간은..

ProblemviewReolsver에 viewname이 null 값으로 들어가는 코드 존재하여 오류와 다른 화면이 사용자에게 노출되고 있음 Cause ✅ 개념model and view 응답처리 DispatcherServler 에게 ModelAndView 객체 를 넘김 viewName엔 화면 페이지가 있는 경로ViewResolver 체인 실행 & InternalResourceView 생성DispatcherServlet의 render(ModelAndView, …) 내부에서, 등록된 ViewResolver 순서대로 resolveViewName("/good/detail" , locale)을 호출보통 마지막에 등록된 InternalResourceViewResolver가 동작하여 InternalResou..

1. 상황 - Redisson 활용하여 트랜잭션 안에서 또 다른 분산락을 설정 중 - @Transactional 사용시에도 락을 얻을텐데 동시에 여러 접속자가 같은 자원을 조회할 때, 왜 락이 제대로 잡히지 않는 것일까 궁금해짐 2. 스프링의 트랜잭션[스프링의 @Transactional]- 프록시 패턴 (트랜잭션 추상화와 AOP)호출될 때 요청을 가로채어 DB 커넥션을 얻고 트랜잭션 처리 시작 서비스 단에서 일일이 커넥션 풀을 얻는 로직을 작성해줄 필요는 없이 프록시 객체에서 수행함 - 트랜잭션 동기화 일관된 처리 가능 (자식 트랜잭션 실패시 부모 트랜잭션까지 전파되어 롤백되는 기능) * DB 커넥션 - 커넥션 얻는 과정 어플리케이션 시작 시점에 커넥션 풀에 이미 필요한 만큼의 커넥션이 생성되어 ..

1. 이유 고민의 시작 @CircuitBreaker 가 적용된 메서드 안에서  @CircuitBreaker 메서드를 호출할 때 applicationContext 에 있는 bean 을 가져오게끔 되어 있음 application.getBean(this.getClass()).getMethod(adaper, url, json); 기존에 메서드는 같은 클래스라면 getMethod를 호출해주면 되지만,CircuitBreaker 함수를 호출하는 부분에서는 applicationContext.getBean을 통해서 메서드를 호출해주고 있음  🧐  왜 같은 클래스의 메서드를 호출하는데 "굳이" 컨테이너에 있는 클래스의 메서드를 실행해주는 걸까?   2. AOP많은 부분에서 '동일하게' 적용되는 코드들은 한데 모아,특정 ..

1. 개요JSSESIONID가 만료되거나 쿠키가 없을지라도(세션 정보 없음) 어플리케이션이 사용자를 기억하는 기능Rememberme 토큰 쿠키를 이용함Remember-me 설정 ….. 2. 문제상황여러 개의 기기를 사용해서 서비스를 이용하고 있는 사용자의 경우 중요 개인 정보가 변경된 경우 자동로그인 기능으로 인해 다른 기기의 사용자가 계속해서 로그인을 하여 서비스 사용할 수 있는 이슈 발생3. 해결 방향현재 remember-me의 쿠키값을 기준으로 사용자를 확인하는 방법을 분석함1) 우선 redis에서 1차적으로 utid를 기준 쿠키값을 저장 후 조회하고 있음2) redis에서 값이 없을 때 쿠키값을 저장하고 있는 테이블에서 일치하는 쿠키값을 찾음=> 이 결과에 따라 success/fail 로직그렇다..