je_record

이전 포스팅에서 Update Lock과 Exclusive Lock을 이용하여 동시성을 제어해본 후, 비교해보았습니다.🔒Update Lock의 경우, 시간은 적게 소요되지만 업데이트 시에만 락이 걸린다는 점에서 현재는 조회수만을 제어하기에 문제가 없지만, Select 쿼리 후 Update가 이루어지는 경우에는 Update 락을 사용하게 되면 문제가 발생할 수 있었습니다. 🔒Exclusive Lock의 경우, 정확성은 보장되지만 row 자체에 락을 걸기 때문에 성능 저하가 발생하는 것을 확인했습니다.  현재 프로젝트에서는 Update Lock을 사용하여도 문제가 없지만, 학습 차원에서 인메모리 db인 레디스의 분산락을 적용해보았습니다.  조회수 동시성 제어를 위한 고민과 Update Lock 적용공연 동..

공연 동행 구인 서비스의 1차 개발이 끝나고,리팩토링 사항 중 한가지인조회수 동시성 제어를 적용해보고자 합니다💪 동시성 문제란??동일한 데이터에 여러 개의 작업이 동시에 접근할 때 발생할 수 있는 문제를 의미합니다. 예를 들어, 하나의 데이터를 수정하려는 두 개의 작업이 동시에 이루어질 때, 한 작업이 데이터를 수정하는 동안 다른 작업이 수정되기 전의 데이터를 바탕으로 수정을 하게 될 수 있습니다. 이로 인해 데이터의 일관성이 깨지고 예상치 못한 결과가 발생하게 됩니다. 아래 코드는 동행 구인글 조회 시, 조회수가 1 증가하도록 설정한 코드입니다.@Service@RequiredArgsConstructorpublic class AccompanyServiceImpl implements AccompanySe..

이전 포스팅에서 커서를 사용하여 무한 스크롤을 구현해보았는데 https://jerecord.tistory.com/207 커서를 사용하여 무한 스크롤을 구현해보자.공연 동행 구인 웹 서비스의 백엔드로 참여하며 동행 구인 게시글 목록 조회 API를 구현하며 커서 기반 페이지네이션을 적용해보았습니다😀 페이지네이션(오프셋과 커서) 페이지네이션하면 대jerecord.tistory.com 검색 필터링 기능을 적용함에 따라, 사용자가 설정한 조건을 바탕으로 검색 결과 동적 제공이 필요해졌습니다👀 동적 SQL 쿼리의 필요성을 느꼈고, 네이티브 쿼리를 작성하기에는, 검색 조건도 많고가독성도 떨어지고 오타 이슈도 많을 것 같아 쿼리를 문자가 아니라 자바 코드로 작성할 수 있게 해주는..

공연 동행 구인 웹 서비스에서 동행 구인 게시글 목록 조회 API를 구현하며많은 양의 동행 구인글 반환이 필요하여서버 부하 방지를 위해 커서 기반 페이지네이션을 적용해보았습니다😀 오프셋 방식과 커서 방식 비교페이지네이션은 모든 데이터를 전달하는 것이 아닌, 특정 개수의 필요한 데이터만 전달하는 방법을 의미합니다.페이지네이션하면 대표적으로 두 가지 방법이 있습니다. 1. 오프셋 기반 페이지네이션오프셋을 사용하게 되면, 오프셋 앞 데이터를 읽고 그 이후의 n개의 데이터를 읽어서 반환하게 되므로, 성능 저하 문제가 발생합니다. 2. 커서 기반 페이지네이션커서 아이디를 기준으로 다음 n개의 데이터를 반환해주는 방식입니다. 간단히 말하면오프셋 기반 방식의 경우 90번째(오프셋) 데..

AOP란? Aspect Oriented Programming, 관점 지향 프로그래밍 횡단 관심사의 분리를 허용함으로써 모듈성을 증가시키는 것이 목적인 프로그래밍 패러다임 횡단 관심사란 어플리케이션의 여러 부분에 걸쳐있는 기능을 의미 ➡️로깅과 트랜잭션, 인증처리와 같은 시스템 공통 처리 영역을 말합니다. 👾 예를 들면 결제 시스템에서 결제 전과 후에 로깅이 이루어지는 경우, 로깅 작업은 결제 메서드에서 공통적으로 이용되는 부분이므로 횡단 관심사가 됩니다. 신용카드_결제(){ // 결제 시작 전 로그 // 로직 // 결제 종료 후 로그 } 포인트_결제(){ // 결제 시작 전 로그 // 로직 // 결제 종료 후 로그 } 쿠폰_결제(){ // 결제 시작 전 로그 // 로직 // 결제 종료 후 로그 } AOP..

롯데시네마 클론 코딩 프로젝트에서 사용자의 티켓 정보를 가져오는 기능 개발 중테이블 간 연관된 정보들이 많아 총 8개의 테이블을 건드려야 하는 상황이 발생했습니다“과연 쿼리문을 8개 사용하는 것이 적합한가?”라는 의문을 가지게 되었습니다🫤 기능 개발 후, 리팩토링을 통해 성능을 향상시켜보았습니다🧙 Refactor1.fetch join을 통해 연관관계 엔티티 함께 조회하기 Refactor2.각 티켓에 대한 티켓 정보는 비동기적으로 가져오기(각 티켓은 서로에게 영향을 미치지 않는 독립적인 데이터이므로) Fetch Join X, 비동기 X - 75349ms(기존 구현)우선 기존에 구현된 코드는 아래와 같습니다!각각의 테이블들에 대해 데이터를 따로 가져오고 있는 것을 확인할 수 ..