Ikjo's Technology blog

트랜잭션 격리수준 Serializable, 왜 사용할까? 온보딩 당시 비지니스 로직을 살펴 보는 중 서비스 레이어 계층에서 스프링이 제공하는 트랜잭션 AOP 기능을 적용 시 트랜잭션 격리수준이 Serializable 로 설정 되어있는 것을 확인할 수 있었다. 참고로, 스프링이 제공하는 트랜잭션 AOP 기능은 개발자가 별도로 트랜잭션 격리수준을 설정하지 않을 경우 데이터소스의 기본 트랜잭션 격리수준을 따르게 된다. @Target({ElementType.TYPE, ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) @Inherited @Documented public @interface Transactional { // ... /** * The transac..

콜백 안에 또 다른 콜백 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 ..

발생 이슈 지난 달 다른 서비스 팀의 친한 백엔드 개발자로부터 원인을 알 수 없는 이상한(?) 현상이 나타나고 있다는 것을 전해 듣고 해당 팀에 가서 어떤 이상한 현상인지 보러갔다. 해당 이슈는 동일한 조회 쿼리를 사용했음에도 불구하고 로컬 환경에서는 데이터 정렬이 정상적으로 처리되어 조회되는데, 개발 서버 환경에서는 데이터 정렬이 비정상적으로 처리되어 조회된다는 것이었다. 👀 쿼리 분석 우선, 그 조회 쿼리가 무엇인지 살펴보았다. 해당 쿼리의 형태는 대략적으로 다음과 같았다. WITH temp_a_tbable AS ( SELECT ... FROM a_table WHERE deleted_at IS NULL ), temp_b_table AS ( SELECT ... FROM b_table WHERE dele..