개발중 동시성 문제를 해결하기 위해 lock을 걸곤 한다. 이때 synchronized를 잘못된 위치에 사용하면 lock이 제대로 걸리지 않으니 주의하자.📌 서론자바와 스프링으로 서버를 개발하다 보면 synchronized를 사용해서 lock을 걸어본 경험이 있을 것이다.또한 스프링 내부를 뜯어보다 보면 종종 synchronized를 사용한 코드들이 보인다. 나는 이것들에 대해 크게 신경 쓰지 않고 있었는데 이번에 인강으로 동시성 문제에 대한 공부를 하던 도중 새롭게 알게 된 사실이 있다. 바로 synchronized는 트랜잭션이 걸린 서비스 코드가 아닌 이 서비스 코드를 호출하는 컨트롤러에 걸어줘야만 동기화가 제대로 동작한다는 것이다.지금부터 코드를 통해 왜 서비스에서 synchronized를 적용시..

코틀린 스프링에서 Spring Validation을 적용하기 위해서는 꼭 알아둬야 할 것이 있다.📌 서론코틀린 스프링으로 개발하던 도중 독특한 문제를 만났다.프로젝트에 spring validation을 적용시켜 requestDto의 유효성을 검증하도록 설계했다. 왜냐하면 코틀린이 null safe 한 언어라지만 클라이언트 측에서 보내는 데이터까지 모두 컨트롤할 수 없기 때문에 클라이언트 요청을 바로 validation으로 검증하여 데이터의 무결성을 보장하고자 했다.  그래서 나는 검증하고자 하는 DTO 필드에 @NotBlank 어노테이션을 적어줬고 HTTPie(Postman)을 사용해 validation을 적용한 필드에 값을 넣지 않고 api요청을 보내봤다. (일부로 오류를 발생시키기 위함) 근데.....

예외가 발생하면 stackTrace는 어떻게 생성될까?📌 서론 RuntimeException이 발생했을 때 (우리가 주로 커스텀 예외를 만들 때도 RuntimeException을 던진다.)우리 개발자들은 예외가 발생하면 로그창에서 stackTrace 로그 내용을 분석하며 쉽게 오류사항을 찾아내곤 한다.스프링은 발생하는 예외를 어떻게 처리하고 stackTrace에 그 내용을 남기는 걸까?이번 포스트에서는 직접 RuntimeException 예외를 발생시키고 이 예외를 처리하는 코드를 따라가 보며 최종적으로 stackTrace를 만들어주는 코드를 분석해 보도록 하자. 이렇게 코드 분석을 따라가다 보면 알게 되는 점은 다음과 같을 것이다.1. RuntimeException은 어떻게 처리되는가 (예외처리 코드..

Spring Event 스레드의 동작원리를 이해해 보자 📌 서론 스프링 이벤트(Application Events)는 기본적으로 발행자(publisher)와 리스너(listener)가 같은 스레드에서 동작한다. 즉, 이벤트를 발행하는 메서드를 호출하면 그 호출을 처리하는 스레드가 이벤트 리스너도 처리하는 것이 기본 동작이다. 이번 포스트에서는 스프링 이벤트와 스레드의 동작 방식을 자세히 알아보자 1. 스프링 이벤트와 스레드 동작 방식 (1개의 이벤트 리스너) 스프링 이벤트의 스레드 동작(동기) 기본적으로, 스프링에서 이벤트를 발행하면, 그 이벤트는 기존 로직을 처리하고 있던 같은 스레드에서 처리된다. 예를 들어 어떤 컨트롤러 메서드에서 이벤트를 발행했다면, 그 이벤트에 대한 처리도 요청을 처리하고 있던 그..

커스텀 어노테이션 적용기 📌 서론 SpringBoot로 개발하다 보면 @Controller, @Service, @Repository, @Transactional, @Component, @Bean 등등 정말 많은 어노테이션을 사용하여 편하게 개발을 한다. 근데 스프링이 제공하는 어노테이션 말고도 개발자가 직접 본인만의 어노테이션을 만들어서 프로젝트에 적용시킬 수 있다는 것을 아는가? 아마 대부분의 개발자들은 알고 있었겠지만 사용해 볼 일은 거의 없었을 것이다. 나는 사용자 커스텀 어노테이션이 어떻게 작성되고 프로젝트에서 사용되는지 내부의 동작원리가 궁금했고 직접 만들어보기로 했다. 지금부터 Spring에 직접 커스텀 어노테이션을 만들어보면서 이게 어떻게 동작하는지 알아보자. 완성된 코드는 아래의 Repo..

스프링은 어떻게 트랜잭션 전파를 처리하는지 알아보자 📌 서론 스프링 프레임워크에서 @Transactional 애노테이션을 사용할 때, 기본적인 전파 수준(propagation level)은 Propagation.REQUIRED다. 이 전파 수준은 현재 진행 중인 트랜잭션이 있으면 해당 트랜잭션에 참여하고, 없으면 새로운 트랜잭션을 시작하는 것이다. 즉, 메서드가 트랜잭션 내에서 실행되도록 보장해 준다. 그런데 이렇게만 알고 넘기기엔 답답한 마음이 들었다. 스프링은 내부에서 어떻게 이 전파 수준을 추출하고 해석해서 동작시키는지 정말 궁금했고 그 내용을 공부했다. 이번 포스트를 통해 그 내용을 공유한다. 이번 포스트는 정말 헷갈리고 어려울 수 있다. 쉽게 이해하기 위해 직접 코드를 따라가 보는 것이 좋다고 ..

일정 시간마다 Redis의 데이터를 RDB에 저장해 보자 📌 서론 내가 만든 요리 SNS어플인 "레시피아"에서는 유저가 레시피를 조회하면 조회수 데이터를 Redis에 계속 누적시킨다. 만약 유저가 레시피 상세보기를 하면 Redis에 저장된 누적 조회수 데이터를 호출하여 화면에서 조회수를 보여주도록 기능을 구현했다. 이렇게 RDB에서 데이터를 가져오지 않고 Redis에서 바로 조회수 데이터를 호출하게 하여 빠른 반응속도와 RDB의 부하를 줄였다. 이렇게 행복하고 편리하게 기술이 적용되었다면 참 좋겠지만 Redis는 휘발성 데이터베이스이기 때문에 문제가 발생하면 데이터가 다 날아가기 때문에 복구 전략이 엄청 중요하다. 이미 Redis에서는 자체적인 복구기능으로 aof, rdb 방식을 지원하지만 이것만으로는..

예외 테스트를 왜 작성해야 하는지 경험한 내용을 공유하고자 한다. 📌 서론 내가 겪은 3가지 문제와 이것의 해결과정을 설명하고자 한다. 1. 안드로이드에서 데이터를 requestDto로 잘 보냈는데 스프링 서버에서는 null로만 받는 문제 발생 2. 1번 문제를 해결했더니 데이터 validation 문제 발생 3. 테스트 코드를 작성했는데 왜 이런 문제들이 발생한 걸까? 1. 첫 번째 문제: 데이터를 null로 받음 문제의 코드 아래의 컨트롤러 코드에 데이터를 보내면 모두 null을 받았다. @RequestMapping("/recipe") @RequiredArgsConstructor @RestController public class RecipeLikeController { private final Re..