Trouble Shooting (6) 썸네일형 리스트형 [Trouble Shooting] 트랜잭션 롤백 문제 : 서비스 분리와 트랜잭션 전파의 중요성 문제 상황- 비밀번호 시도 횟수를 증가하기 위해 비밀번호가 틀렸을 경우 시도 횟수를 증가 시켜야 하지만 에러를 던져주기 때문에 롤백이 되어 시도 횟수를 증가시킬 수 없었다. 해결 과정- REQUIRED (Default) - 별도의 트랜하나잭션이 실행되어도 부모 트랜잭션에 종속되어 실행된다. 자식 트랜션에 @Transactional(propagation = Propagation.REQUIRES_NEW) 설정을 넣어두어서 부모에 에러가 발생하더라도 자식 트랜잭션은 실행이 되도록 하였습니다.주의 사항 - 부모 자식 트랜잭션이 위치하여 따로 실행시킨다고 하여도 같은 서비스 내부에 위치하면 하나의 트랜잭션으로 처리되어 독립적인 서비스에 두어야한다. [Trouble Shooting] 트랜잭션 롤백 문제 : 서비스 분리와 트랜잭션 전파의 중요성 1. 로그인 시도 코드 (비밀번호 일치 확인 | 틀렸을 경우 로그인 시도 횟수 증가 | 6회 이상 틀렸을 경우 계정 잠금)/** * 로그인 * @param request * @return */ @Transactional public String signInAuth(AuthSignInRequestDto request, HttpServletResponse response) { // 직원 로그인 if (request.getRole().equals(UserRole.MASTER.name()) || request.getRole().equals(UserRole.MANAGER.name())) { // 가입 여부 확인 .. [Trouble Shooting] 모든 서비스 시큐리티 적용 시 문제점 # 문제 상황스프링부트 MSA 환경에서 각 서비스마다 시큐리티 컨텍스트를 설정할 때, 각 서비스에는 user 테이블이 존재하지 않아 컨텍스트 설정에 어려움이 있었습니다. 이를 해결하기 위해 authclient를 사용하여 인증 및 사용자 정보를 처리하려 했으나, 이 과정에서 여러 가지 문제가 발생했습니다.client 호출 시 매번 헤더 값 등을 처리하는 반복적인 코드가 많았고, 이를 requestInterceptor를 통해 개선하였습니다.그러나 authclient 호출로 인해 HTTP 요청이 한 번 더 발생하면서 필터를 다시 타게 되었습니다. 이때, 필터에서 헤더 값이 비어 있는 문제가 발생해, 초기에는 빈 컨텍스트를 설정하는 방식으로 처리하였으나, 이는 안전하지 못한 방식이었습니다. # 해결 과정문제를 .. [Trouble Shooting] Redis 페이지 검색 조건 키 설정 문제 문제 정의Redis 페이지 검색 조건 키 설정 문제Redis를 사용하여 페이지 검색 시, Redis 키를 page와 size로만 설정하고 조회할 경우, 검색 조건이 제대로 반영되지 않는 문제가 발생했습니다.예를 들어, 다음과 같이 @Cacheable을 설정할 경우, page와 size가 0이면 캐싱된 데이터가 무조건 조회되어 검색 조건이 적용되지 않는 문제가 발생합니다:이때, page와 size만으로 키가 설정된 상태에서 검색 조건을 추가하여 조회하게 되면 기존에 캐싱된 데이터가 반환되어 검색 조건이 반영되지 않은 잘못된 데이터가 조회됩니다.@Cacheable(cacheNames = "hubSearchCache", key = "{#pageable.pageNumber, #pageable.pageSize}".. [Trouble Shooting] 기상청 API 호출 시 URL 이중 인코딩 문제 문제 정의URL 인코딩 문제UriComponentsBuilder를 사용하여 serviceKey (인코딩 된 인증 키)를 설정하는 과정에서 문제가 발생했습니다.encode()를 사용하더라도 이중 인코딩 문제가 발생하여 URL이 제대로 완성되지 않았습니다.이로 인해 계속적인 serviceKey 에러가 발생했습니다. 해결 과정UriComponentsBuilder 기본 설정의 인코딩 문제serviceKey와 UriComponentsBuilder 간의 이중 인코딩 문제로 인해 에러가 계속 발생했으며, 이는 serviceKey가 올바르게 인코딩되지 않았음을 나타냈습니다.다른 URL 조작 클라이언트 사용 고려UriComponentsBuilder 대신 다른 URL 조작 클라이언트를 사용하는 방법을 고려하거나, UriC.. [Trouble Shooting] 소프트 딜리트로 인해 유니크 제약 설정 문제 문제 상황소프트 딜리트(is_delete 플래그)를 사용하는 경우, 데이터를 삭제할 때 물리적으로 데이터가 삭제되지 않고 논리적으로만 삭제 처리됩니다. 하지만 실제 데이터는 여전히 데이터베이스(DB)에 남아 있기 때문에, 동일한 테이블에서 유니크 제약 조건(예: 특정 필드의 값이 중복되지 않아야 하는 조건)을 사용하는 경우 문제가 발생할 수 있습니다.삭제된 데이터가 유니크 제약 조건을 위반하게 되어, 새로운 데이터를 삽입하거나 수정할 때 충돌이 발생하는 상황입니다. 즉, 논리적으로 삭제된 데이터와 남아 있는 데이터 간에 유니크 제약 조건 충돌 문제가 발생하는 것입니다. 해결 과정유니크 제약 조건 수정논리적으로 삭제된 데이터가 유니크 제약 조건을 위반하지 않도록 하기 위해, 유니크 인덱스를 생성할 때 i.. 이전 1 다음