개요최종 프로젝트를 시작하면서, 인증/인가 부분을 한 번 더 맡게 되었다. 이전에는 RefreshToken을 RDB에 관리하며, 'RefreshToken을 Redis에서 관리하는 것이 더 낫지 않을까?'란 느낌이 있었는데, 정확히 어떤 점이 좋은지는 머리 속으로 그려봐도 크게 그려지지는 않았다. 인증/인가 부분을 한 번 더 맡게 된 김에 이번에는 Redis를 이용하여 RefreshToken을 관리해보고, 이전에 잘못 이해했던 RefreshToken 사용 방식을 다시 공부하며 더불어 RDB로 관리할 때의 차이점을 비교해보려 한다. 요구사항함께 살펴볼 부분은 다음과 같다.로그인 시 토큰들을 발급받으며 RefreshToken을 Redis에 저장한다.AccessToken 만료 시 RefreshToken을 통..
개요최근에 캐치 테이블을 타겟 클론하여 프로젝트를 진행하였다.예약 하기 전 해당 시간에 대한 선점을 먼저 요구하는 예약기능의 요구사항이 기억에 남는다. 최근에 이 기능에 대한 로직을 쭉 살펴보다가 개선점이 보였다.기존 로직을 리팩토링 후 글로 남겨본다. 요구사항예약 시, 요구사항은 다음과 같다.가게의 예약시간을 클릭 시, 그 시간에 대해 해당 유저는 7분 동안 예약 선점권을 갖는다.예약 선점권을 가진 유저가 상세정보를 입력 후 예약을 할 수 있다. 기존 코드@Service@RequiredArgsConstructorpublic class MemberReservationService { private final ReservationTimeRepository reservationTimeReposito..
개요DB에 관심을 갖고 테코톡과 Real MySQL을 읽으며, 트랜잭션과 동시성 처리 등에 관심을 갖게 되었다. 그 중 가장 어렵다고 느낀 트랜잭션 격리 수준에 대한 개념을 정리하려 한다. 트랜잭션 격리 수준은 4단계로 나누어지며, 각 단계 별 부정합 문제점들을 갖고 있어 뒤로 갈 수록 갖고 있던 문제점들을 해결해 나간다. 1. READ UNCOMMITTED각 트랜잭션의 변경내용이 COMMIT 혹은 ROLLBACK 여부에 상관없이 다른 트랜잭션에 노출된다. 예시사용자 A가 트랜잭션을 시작함과 동시에 emp_no = 50000 인 사원을 INSERT 후 COMMIT은 하지 않는다.하지만 사용자 B가 테이블 SELECT 시, emp_no = 50000 인 사원이 조회된다. 트랜잭션이 COMMIT 되기도 ..
