PessimisticLockException은 왜 발생할까?MySQL의 동작 원리와 함께 이해하는 비관적 락 예외JPA를 사용할 때 종종 마주치는 예외 중 하나가 PessimisticLockException이다. 비관적 락이라는 개념은 직관적으로 "다른 트랜잭션이 건드리지 못하도록 선제적으로 막는 것"으로 이해할 수 있지만, 이 예외가 발생하는 정확한 원인을 명확히 이해하려면 DBMS, 특히 MySQL이 비관적 락을 어떻게 처리하는지를 아는 것이 중요하다. 비관적 락(Pessimistic Lock)이란?비관적 락은 트랜잭션이 데이터를 읽거나 수정하려고 할 때, 다른 트랜잭션이 해당 데이터를 동시에 변경하지 못하도록 락을 거는 방식이다. 주로 SELECT ... FOR UPDATE 또는 SELECT ....

@Qualifier: 빈 충돌 해결Spring에서는 @Autowired를 통해 의존성을 자동 주입할 수 있다. 하지만 같은 타입의 빈이 여러 개 등록되어 있을 경우, Spring은 어떤 빈을 주입해야 할지 판단하지 못하고 예외를 발생시킨다. 이럴 때 사용하는 도구가 바로 @Qualifier이다. 1. 문제 상황: 같은 타입의 Bean이 2개 이상일 때다음과 같은 구조를 생각해보자.public interface NotificationService { void send(String message);}@Servicepublic class EmailNotificationService implements NotificationService { public void send(String message)..

@ConfigurationProperties: 설정을 객체처럼 다루는 방법Spring Boot를 사용하다 보면, application.yml 혹은 application.properties에 설정값을 넣고 이를 Java 코드에서 읽어야 할 때가 많다. 대부분은 @Value를 사용해 간단히 값을 주입받지만, 설정 항목이 많아질수록 유지보수가 어려워진다. 이런 상황에서 @ConfigurationProperties는 설정값을 객체처럼 바인딩해주는 강력한 도구다. 특히 대규모 프로젝트나 외부 연동 API 설정처럼 계층적이고 반복적인 설정이 필요할 때 더욱 유용하다. 1. 기본 개념@ConfigurationProperties는 application.yml 혹은 application.properties의 값을 PO..

Lombok @Data: 모든 것을 자동으로 만들어줄까?Java는 기본적으로 보일러플레이트 코드가 많기로 유명하다. 특히 도메인 객체를 작성할 때 getter, setter, toString(), equals(), hashCode(), 생성자 등을 반복해서 작성하는 일은 흔한 일이다. Lombok은 이러한 문제를 해결하기 위해 등장한 라이브러리이고, @Data는 그중에서도 가장 많은 기능을 한꺼번에 제공하는 애노테이션이다. 하지만, "모든 것을 자동으로 만들어준다"는 점은 동시에 주의가 필요한 신호이기도 하다. 이 글에서는 @Data가 제공하는 기능, 내부적으로 포함된 애노테이션, 사용 시 고려할 점을 함께 살펴본다. 1. @Data가 생성하는 메서드@Data는 다음과 같은 Lombok 애노테이션을 묶..

Spring Boot 기본 ExceptionResolver 3종 완전 정리Spring MVC에서 예외가 발생하면 DispatcherServlet은 내부적으로 HandlerExceptionResolverComposite를 통해예외 처리 흐름을 제어합니다. 해당 Composite에는 기본적으로 다음의 Resolver들이 등록되며, 순서대로 예외 처리를 시도합니다.등록 순서ExceptionHandlerExceptionResolverResponseStatusExceptionResolverDefaultHandlerExceptionResolver각 Resolver는 다음과 같은 상황에서 사용됩니다. 1. ExceptionHandlerExceptionResolver정의@ExceptionHandler 애노테이션이 붙은..

@ControllerAdvice와 @ExceptionHandler 완전 정복도입 배경: 왜 전역 예외 처리가 필요한가?서비스를 운영하다 보면 예외는 피할 수 없는 현실입니다. 특히 웹 애플리케이션에서는 다음과 같은 요구가 자주 등장합니다:클라이언트에게 일관된 에러 응답 포맷을 제공해야 한다.추후에 API 스펙이 변경되면, 프론트엔드의 수정이 불가피하다.따라서 많은 부수효과가 발생한다.비즈니스 예외와 시스템 예외를 구분해서 다뤄야 한다.예외 발생 시 적절한 로그, 알람, 후속 처리를 구성해야 한다.컨트롤러마다 중복되는 try-catch를 제거하고 싶다.Spring은 이러한 요구를 해결하기 위해 전역 예외 처리 메커니즘을 제공합니다. 그 핵심은 @ControllerAdvice와 @ExceptionHandle..

JPA QueryHint, 정말 성능에 도움이 될까?“@QueryHint 쓰면 성능이 좋아진다던데요?”반은 맞고, 반은 틀립니다. 이 글에서는 JPA Hint의 현실적 쓰임새와 한계, 그리고 실무에서 언제 써야 의미 있는지를 정리해봅니다. Hint란 무엇인가?JPA에서 제공하는 @QueryHint는 쿼리 실행 시 Hibernate나 JPA 구현체에게 특정 힌트를 전달하여 동작을 제어하는 기능입니다. 사용 예시Dirty Checking을 생략해서 flush를 방지쿼리 결과를 2차 캐시에 저장JDBC 쿼리에 타임아웃 적용@QueryHints(@QueryHint(name = "org.hibernate.readOnly", value = "true"))@Query("SELECT m FROM Member m")Li..

JPA N+1 문제, 왜 생기고 어떻게 해결할까?많은 개발자들이 JPA를 쓰면서 한 번쯤은 겪는 고질병, 바로 N+1 문제다.처음엔 성능 잘 나오다가도, 조회 건수가 많아지면 갑자기 쿼리 수가 폭증하고 응답 시간이 기하급수적으로 느려진다.그리고 로그를 보면 이렇게 되어 있다.SELECT * FROM member;SELECT * FROM team WHERE team_id = 1;SELECT * FROM team WHERE team_id = 2;SELECT * FROM team WHERE team_id = 3;...한 번의 조회로 끝날 줄 알았던 쿼리가 무려 N+1번이나 나간다. N+1 문제란 무엇인가?N+1 문제는 JPA에서 1번의 쿼리로 N개의 결과를 가져온 후, 그 결과 각각에 대해 추가 쿼리가 1번씩..