개요프로젝트가 끝나고 팀원과 함께 개선할 쿼리를 추렸다. 최근에 인덱스에 대해 공부하고 있기도 하고 개념적으로만 알고 있던 인덱스를 직접 추가하여 쿼리 성능을 개선 해보았다. 테이블쿼리에 사용된 테이블은 다음과 같다 roomcreate table room_table ( room_id bigint not null, room_meeting_info_id bigint, room_title varchar(255), room_description varchar(255), room_image_url varchar(255), room_head_count integer, ..
개요최종 프로젝트를 시작하면서, 인증/인가 부분을 한 번 더 맡게 되었다. 이전에는 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 되기도 ..
