많은 블로그에서 RedisConfig, CacheManager 를 설정하라고 한다. 그래서 이것저것 테스트해봤는데 아무것도 설정하지 않고 Redis와 연결만 시켜준 후에 Spring에서 제공하는 Cache 관련 어노테이션을 사용하니 의도와는 다르게 자동으로 Redis에 저장이 되었다...... 한참 찾아보니, gradle에 아래 설정을 추가하면 자동으로 default 값이 ConcurrentMapCache 에서 RedisCache로 설정된다고 한다. implementation 'org.springframework.boot:spring-boot-starter-data-redis' 하지만 Redis 에 TTL, 직렬화를 비롯한 여러 가지 설정을 본인의 애플리케이션에 적합하게 설정하기 위해서는 RedisCon..

이커머스 프로젝트를 하다보니 동시성 문제가 여러 곳에서 일어날 수 있다는 것을 느꼈다. 처음엔 Syncronized를 붙여서 동시성을 해결한줄 알았지만 여러 서버에서 동시 요청을 했을 때 Syncronized는 동시성 문제를 해결해줄 수 없음을 깨달았다. (한 프로세스 내에서만 동기 처리를 해줌) 그래서 동시성 문제를 해결하기 위해서 트랜잭션의 격리성을 공부하게 되었고, 트랜잭션의 격리성을 공부하다 보니 '동시성을 어떠한 방식으로 해결할까' 에 대한 고민을 할 수 밖에 없었다. 가장 보편적인 방법으로 낙관적 락과 비관적 락이 있어서 두 Lock을 비교하며 정리해봐야겠다. - 낙관적 락 : 낙관적 락은 DB가 아닌 Application Level 에서 동시성을 해결한다. @Version을 통해 버전을 관리..

ACID 중 Isolation을 의미하는 격리성에 대해서 간단하게 정리해보려고 한다. 여기서 격리성의 의미는 실행중인 트랜잭션에 다른 트랜잭션이 접근할 수 없음을 의미한다. 그리고 이러한 격리성의 정도는 직접 정할 수 있다. 격리성의 정도와 그에 따라 발생할 수 있는 문제점을 정리해보겠다 ! - Read UnCommitted : 트랜잭션인 커밋되기 전에 다른 트랜잭션인 읽기를 허용하는 것이다. : 데이터의 정합성 문제를 일으킨다. (Dirty Read, Non-Reatable Read, Phantom Read) - Read Committed : 커밋이 확정된 데이터만 읽도록 허용한다. 커밋되지 않은 데이터는 실제 DB가 아닌, Undo로그에 있는 이전 데이터를 가져온다. -> Dirty Read를 해결할..

https://velog.io/@ehdrms2034/%EC%8A%A4%ED%94%84%EB%A7%81-%EB%B0%B0%EC%B9%98-Job-%EC%84%A4%EC%A0%95%EA%B3%BC-%EC%8B%A4%ED%96%89 스프링 배치 - Job 설정과 실행 tags: Job 인터페이스 구현체는 다양하고, 설정방법도 다르고 Builder 패턴으로 이를 추상화한다.Job(보통 Step을 가지고 있는)은 JobRepository가 필요하다.JobRepository는 BatchConfigurer를 통해 설정한다.위에 velog.io https://yhmane.tistory.com/199 [SpringBatch] Multi Job 등록 | 지정된 Job 실행하기 들어가며 SpringBatch를 처음 접하게 ..

TrendPick의 주요기능 중 하나인 상품 추천 기능에 관해서 간단히 설명하자면 판매자는 상품을 등록할 때 상품에 맞는 태그를 선택하여 등록할 수 있다. 회원은 회원가입시 관심 있는 태그를 선택할 수 있다. 회원은 상품 조회, 장바구니 담기, 구매 등 행동패턴에 따라 태그의 점수가 누적된다. 만약 회원이 가지고 있지 않은 태그라면 새롭게 추가되고 기존에 있던 태그면 점수가 누적된다. 아래 코드는 해당 내용을 구현한 것이다. ==FavoriteTagService== public void updateTag(Member member, Product product, TagType type) { Set tagList = tagRepository.findAllByProduct(product); Set tags =..

querydsl 을 사용한 예시를 보면 대부분 left join을 사용하는 것을 볼 수 있었다. 이번 팀 프로젝트를 진행하며 내게 querydsl을 알려주시던 분은 항상 left join을 사용했다. 그런데 어떤 이유로 left join을 사용하는 것인지, 모든 경우에 left join을 사용해야 하는지가 궁금해졌다. 그래서 찾아본 결과로 대부분의 상황은 left join으로 해결이 되긴 했다. 왜냐하면 left join 으로 필요한 entity의 결과를 모두 조회한 후, 조인조건에 맞게 조인테이블을 합친 후 where절로 다시 한 번 조건을 걸어주는게 일반적이기 때문이다. 이걸 inner join으로 사용한다면 on에서 where의 역할을 수행한다고 볼 수 있다. 하지만 성능면에서 보면 left joi..