Ikjo's Technology blog

JPA 에서의 영속성 컨텍스트와 스프링 트랜잭션JPA 에서 영속성 컨텍스트는 엔티티를 영구 저장하는 환경으로서 엔티티 매니저로 엔티티를 저장하거나 조회하면 엔티티 매니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다. 이때 영속성 컨텍스트가 엔티티를 관리하면 여러가지 이점이 있다. 대표적으로 1차 캐시, 트랜잭션을 지원하는 쓰기 지연, 변경 감지, 지연 로딩 등이 있다. 스프링이나 J2EE 컨테이너 환경에서 JPA 를 사용하면 영속성 컨텍스트의 생존 범위가 스프링  트랜잭션의 범위와 같다. 즉 스프링에서 지원하는 트랜잭션을 시작할 때 영속성 컨텍스트가 생성되고 해당 트랜잭션이 끝날 때 영속성 컨텍스트를 종료하는 것이다. 참고로 같은 트랜잭션 안에서는 항상 같은 영속성 컨텍스트에 접근한다.  스프링 트랜잭..

콜백 안에 또 다른 콜백 spring webflux 에서 제공하는 WebClient 를 기반으로 3rd party server 와 통신하면서 retry 처리를 해줘야 할 일이 있었다. 여기서 말하는 retry 처리란 아래와 같았다. 1. our server 는 target server 에 요청 시 access token 을 함께 전송한다. 2. target server 는 our server 의 요청을 처리하기 전 access token 이 유효한지 검증한다. 3. (access token 이 만료된 경우) target server 는 our server 에 access token 이 만료되었다고 응답한다. 4. (해당 응답을 받은) our server 는 target server 에 새로운 access..

발생 이슈 입사한지 2달 정도 됐을 당시 주어진 Task 를 진행하는 중에 기존 코드 상 트랜잭션 애노테이션이 붙어있음에도 불구하고 JPA 영속성 컨텍스트에서 제공하는 Dirty check 기능이 활성화되지 않고 있었던 이슈가 있었다. 이로 인해 update 쿼리가 나가야할 때 나가지 않는 문제가 있었다. 코드의 상황은 대략적으로 아래와 같았다. @Slf4j public class TokenManager { @Transactional public void updateToken() { try { Token token = externalApiTokenRepository.find().orElseThrow(); token.update(); } catch (Exception e) { log.error(".... ..

발생 이슈 gRPC(google Remote Procedure Call) 를 통해 요청을 받은 후 spring-data-jpa 에서 제공하는 SimpleJpaRepository 의 save 메서드를 호출하는 시점에 아래와 같은 에러가 발생했다. java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and ..

발생 이슈입사한지 얼마 안되 배정받았던 소소한(?) 이슈가 있었다. FE 측에서 BE 측에 페이지네이션 기능을 포함한 목록 조회 API 를 호출했는데, 분명히 페이지네이션 관련 파라미터를 제대로 할당했음에도 불구하고 페이지네이션된 데이터가 아니라 전체 데이터가 조회된다는 것이었다. 👀  코드 분석당시 나는 우선적으로 해당 API 의 로직 중 데이터베이스에 접근하는 계층의 로직을 우선적으로 살펴보았다. 해당 로직을 살펴보니 엔티티 매니저 의존성을 직접 주입받고 이를 활용하여 데이터베이스에 접근하고있었으며, 네이티브 쿼리를 이용하고있었다. 이때 동적 검색 기능을 구현하기 위해 일일이 조건절을 만들어 문자열 쿼리를 만들어주고 있었다. 근데, 쿼리를 생성하는 로직을 아무리 살펴봐도 페이지네이션을 설정하는 부분..