Spring에서 데이터베이스 트랜잭션은 @Transactional로 관리됩니다. 이 애노테이션은 AOP 기반 프록시가 트랜잭션 경계를 만들어 주는 방식으로 동작하며, 애플리케이션은 JPA를 통해 DB에 접근합니다.이렇게 여러 구성 요소가 겹쳐 DB 트랜잭션을 사용하다 보니 실제 동작을 정확히 이해하지 못한 채 무작정 @Transactional을 붙이거나 흐름을 파악하지 못해 시행착오를 겪는 경우가 많습니다. 그래서 이번 글에서는 로그를 확인하면서 프레임워크가 트랜잭션을 실제로 어떻게 시작·합류·커밋·롤백하는지 살펴보려고 합니다. TL;DR결론: REQUIRED → REQUIRED에서 내부 RuntimeException(unchecked exception)은 바깥까지 전파되어 전체 롤백된다.가장 보편적으로..

Spring에서 Redis 서버에 연결하려면 무엇이 필요할까? Spring에서 Redis에 연결하려면 클라이언트 드라이버(Lettuce, Jedis 등)가 필요합니다.RedistTemplate은 RedisConnectionFactory를 통해 RedisConnection을 얻고 이 커넥션을 사용해 명령을 실행한 뒤 반납합니다.RedisConnection은 Spring Data Redis가 제공하는 추상화 계층으로 내부적으로 Lettuce나 Jedis 같은 클라이언트 라이브러리를 사용해 실제 Redis 서버와 통신합니다.Spring Data Redis는 클라이언트별로 전용 팩토리를 제공합니다. 즉, 어떤 클라이언트를 쓸지는 어떤 커넥션 팩토리를 생성하느냐로 결정됩니다.LettuceConnectionFac..

이번 글에서는 @Transactional 사용 시 유의해야 할 사항 중 특히 조용한 롤백 현상에 대해 이야기합니다.겉으로는 정상 처리된 것처럼 보이지만 실제로는 데이터가 커밋되지 않는 상황이 발생할 수 있습니다.왜 이런 일이 일어나는지 그리고 이를 어떻게 예방할 수 있는지 살펴봅니다.이커머스, SNS의 "좋아요 수" 등록 기능의 멱등성 처리 설계 "좋아요 등록은 멱등해야 한다."라는 요구사항을 개발하기 위해 DB 유니크 제약을 사용했다. 그래서 아래 단계로 생각하고 코드를 작성했다.1. 좋아요 등록이 되어 있으면 익셉션이 발생할 것이다. 2. 해당 익셉션을 잡아서 비즈니스 익셉션을 발생하게 하면 호출부에서 처리할 수 있겠지//LikeUseCase@Transactionalpublic LikeResult.L..

스프링 프레임워크의 핵심적인 역할 중 하나는 의존성 주입(Dependency Injection)을 통해 객체 생성과 관리 책임을 개발자 대신 수행하는 것입니다. 이러한 역할을 가능하게 하는 주체가 ApplicationContext, 즉 스프링의 IoC 컨테이너입니다.이 글에서는 스프링이 애플리케이션 실행 시 어떻게 컴포넌트를 탐색하고, 어떤 방식으로 빈을 등록하는지를 정리했습니다.또한 @Component와 @Bean이 각각 어떤 상황에서 사용되는지, 자동 구성과 명시적 설정의 차이도 작성하였습니다. 스프링은 의존성 주입(DI)을 통해 객체 생성과 관리를 개발자 대신 수행함이 역할을 담당하는 주체는 ApplicationContext, 즉 IoC(의존성주입) 컨테이너애플리케이션 실행 시, 스프링이 컴포넌트를..

보호되어 있는 글입니다.

Spring Security는 여러 필터에서 OAuth2.0 인증을 처리하는데요. 필터 목록을 갖고 있는 FilterChainProxy을 확인 해보면 디버깅의 실마리를 찾을 수 있습니다. 스프링 시큐리티가 어떤 식으로 OAuth2.0을 구현하는지 또는 에러가 났는데 API 호출로는 에러가 났다는 것 이외에 별다른 정보가 없을 때 디버깅하는 방법을 소개하겠습니다. 1. FilterChainProxy 의 doFilter 메서드 중 원하는 곳에 break point를 겁니다. 스프링 시큐리티 디버깅을 위해 제일 처음 FilterChainProxy에 브레이크 포인트를 걸어서 확인하는 이유는 Spring Security를 사용하면 서블릿 필터는 FilterChainProxy라는 스프링 빈에 필터를 위임합니다. 즉..

스프링 시큐리티에 아키텍쳐에 대해 하나씩 알아보고자 합니다. 처음은 DelegatingFilterProxy, FilterChainProxy로 서블릿 컨테이너와 스프링 컨테이너의 분리로 인해 발생하는 아키텍쳐에 대해 알아보려 합니다. 기반 지식 먼저 서블릿 컨테이너와 스프링 컨테이너를 도식화한 모습은 아래와 같습니다. [출처: mangkyu.tistory.com/18] web context는 서블릿 컨테이너가 포함된 부분으로 톰캣같은 WAS서버가 담당합니다. 인증/인가에 대한 다양한 요구사항 처리 서블릿 필터는 서블릿 스펙에 정의된 기술로 서블릿 컨테이너에서 생성되고 실행되는 객체입니다. 그러므로 스프링 컨테이너에 접근해서 스프링 빈(Bean)을 주입해서 사용할 수가 없습니다. 하지만 인증/인가에 대한 다..

DB에 따라 기본키 생성 전략의 디폴트 값이 달라지기 때문에 MySQL을 기준으로 구현한면, 원하는 전략을 명시적으로 코드로 남겨두시길 추천한다. 결론 : AUTO 전략이 DB마다 다르게 채택되고, Mysql에서는 sequence가 따로 없기 때문에 table 전략이 결국 사용됨을 알았습니다. 조사하면서 table 전략은 사용 이유가 확실할 때만 사용하는 것이 좋을 것 같다고 생각했는데요. 지금의 경우 PK가 숫자로만 구성된다면 굳이 table로 PK가 관리되지 않아도 될 거라 판단합니다. @GeneratedValue 로 기본키 전략 4가지 1. IDENTITY 전략 사용법 : @GeneratedValue(strategy = GenerationType.IDENTITY) DB의 AUTO_INCREMENT를..

@Embeddable 사용한 이유와 장점 관련성이 있는 값들을 의미 있는 객체로 묶어서 관리하면서 객체의 응집도가 높아지는 효과를 기대하고 사용. 공유할 수 있는 객체 이면서 변경할 수 없도록(불변) 사용가능한 것이 @Embedded 타입의 장점이라고 생각합니다. import javax.persistence.Embeddable; @Embeddable public class Address { private String country; private String city; private String gu; }

JPA 엔티티 양방향 참조에 대한 생각 양방향 참조에 대한 질문 양방향 참조를 걸어주신 이유가 있을까요? 양방향 참조를 걸어줄 필요가 없다면, 단방향 참조를 활용하시는 것이 좋습니다. 왜 그럴까요? 단방향 참조 외에 양방향 참조를 굳이 써야 할 경우가 있다면, 언제일까요? 엔티티 참조에 대한 내 생각 먼저 양방향 참조로 엔티티를 모두 작성하고 개발하였다. 이유는 모든 연관관계를 양방향으로 우선 두고, 기능을 개발하면서 하나씩 고민해나가는 방향으로 잡아가기로 했었기 때문이다. 일단 DB 기반으로 관계가 있을수 있다는 것을 표시하고 개발해 나가면서 해당 관계의 필요유무를 고민해 나가려고 했던 것이었다. 그러면서 참고자료의 내용을 읽어보면서 단방향 참조를 활용하는 것이 좋은 이유를 생각해보면, 올바르게 모델링..

'org.springframework.boot' version '2.7.0' 끝이 0으로 끝나는 버젼은 마이너 버전이라고 한다. 마이너 버전은 사용 추천하지 않는다.

org.springframework.web.servlet.config.annotation.WebMvcConfigurer WebMvcConfigurer 스프링프레임워크에서 제공하는 config 관련 interface이다. 구현클래스 WebMvcConfigurerAdapter deprecate 되었다. 이유 알아보기 공부했던 이유 메세지 컨버터, objecMappter에 대해 알아보고 싶었다. API request, response 속성들의 데이터 타입이라던지, 속성의 맵핑 시, 잘 되지 않았을 때 무엇을 봐야 하고 해결을 해나가기 위해 공부하고 싶었다. 공부해보니 스프링의 동작원리를 알아야 했으며 그래서 키워드로 검색해 이해하기엔 한계가 있었다. 그래도 토비의 스프링은 설명이 워낙 자세해서 제일 유용한 자..