고구마서재 프로젝트

공계란씨 (Concurrency)나도 한 번 잡아보려고 이빨 바득바득 갈았는데, 이참에 한 번 잡아봤다.문제 상황은 다음과 같다.서평픽 (서평 좋아요) 등록 시 픽커(서평픽한 사람)와 리시버(서평픽 받은 사람) 모두에게 포인트를 지급한다.픽커는 상관없지만, 만약에 동시

🎯 사건의 발단 Docker Compose 를 활용해서 서비스 아키텍처를 구성하는 과정에서 발생한 문제다. 결론부터 말하자면, > docker compose 의 depends_on 속성 만으로는 컨테이너 간 의존성을 만족할 수 없다. 🔍 톺아보기 Docker

저번 Docker Compose 포스팅 2편이다.글 쓴 목적은 두 가지.Docker Compose 써야할 이유를 보강해왔다DB 컨테이너랑 Server 컨테이너랑 실행 시점 함정 해결법을 보강해왔다Flyway 적용한 걸 보여주고 싶었다한마디로, 도커를 써야하는 명분작을

첫 직장 다닐때 우리팀은 CI는 커녕 테스트 코드도 안 만들고 작업을 했었다.그때를 생각하면 도대체 어떻게 굴러갔던건지 이해가 안 된다.애초에 개발을 하고 개발자가 직접 테스트를 하던가, 아니면 QA 분들이 엄청 고생했겠지.심지어 제대로 동작하지 않는 코드 머지해서 한

멀티모듈을 적용해봤다.적용한 이유는 부끄다만 솔직히 말하면 그냥 써보고 싶어서 적용해봤다.'해보면서 체감을 해보자' 라는 생각이었다.하지만 멀티모듈을 적용하면서 이런저런 애로사항을 겪어보고 내린 결론은 관심사 분리다. 특히 이번 플젝에서 포인트 관련 로직을 별도 모듈로

도서 테이블에 ISBN 이라는 컬럼이 있다.국제적으로 정해주던가 아무튼 도서를 출판할 때 일련번호를 부여받고 세상에 나온다.시중에 나와있는 거의 대부분의 도서는 ISBN이 존재한다.내 독립출판 서평서재 프로젝트에서 가장 근간이 되는 데이터라고 할 수 있다.문제 상황을

지난번엔 서버에서 발생할 동시성 문제를 해결해봤다.정합성 때문에 깎아먹은 서버 성능을 높이고자 방법을 찾아봤다.그리고 두 가지를 찾아내었다.ETag 적용해서 응답 패킷 줄여보기Cache 적용해서 응답 시간 줄여보기후술 하겠지만 두 방법의 목적과 방식이 다르다. 하지만

지난번 포스팅에서 Spring 의 @Transactional 어노테이션이 JPA 비관적 락에 주는 영향을 파악하고 트랜잭션의 전파속성을 REQUIRES_NEW 로 설정하여 동시성 문제를 해결했다.하지만 놀랍게도 문제는 해결된 것이 아니었다. (놀라놀라워)데드락이 발생했