회의록

[ooMia]

• 개발 현황 통합

• 상세 내용은 각 레포의 Discussions 또는 Issues 링크

  • Discussions

    모든 내용 댓글처럼 자유롭게
    많아도 상관 없음
    단, 내용은 짧게

  • Issues

    구현 예정된 사안에 대해 포스팅처럼 깔끔하게
    이슈 발행은 보수적으로
    발행 전 동일 이슈 존재했는지 확인

Closes #1

[haxr369]

추후 진행 계획

Spring과 DB를 연결하고 스레드 안전하게 데이터를 업데이트하기

문제의 기본 배경
spring-concurrency-thread와 같이 카운터.

문제 기본 조건

1. 간단한 ERD (추후 확장하기 쉽도록)
2. JPA를 사용해야할 필요가 있는 시나리오
3. DB 격리 수준에 따라 발생할 수 있는 상황 재현할 수 있어야함

사용 예정인 기술

• Pessimistic Lock
• Optimistic Lock
• Named Lock
• (추후) Redis

[ooMia]

각각의 Lock 방식이 사용되기에 좋은 시나리오가 필요하겠네요!

• JPA - 카운트 문제 상황 빌드업 #5

[ooMia]

프로젝트 초기화

1. web 없이 jpa만 사용
2. multi-threading 환경에서 jpa에 대한 동시성 제어: transaction
3. 트랜잭션 수준 설정과 lock(@haxr369), mvcc(@ooMia) 등의 방식으로 문제 해결
4. e-commerce 도메인 접목 - 참조 JPA - 카운트 문제 상황 빌드업 #5

[haxr369]

프로젝트 구현

1. 물리적 테이블 명을 애플리케이션에서 관리하지 않도록
2. 상품을 물리적 상품의 상태와 추상적인 상품의 메타데이터로 분리
   • 현실적으로 물건을 관리하기 위해선 물건에 고유한 ID를 부여하고 주문 확인, 배송 중 같은 상태를 가질 수 있어야함.
   • 상품의 메타데이터에는 가격, 수량, 공급자 정보, 등등 추상적인 상품의 정보를 저장한다.
3. spring profile 사용
   • 운영 환경 마다 다른 설정 파일을 spring 애플리케이션에 적용하기 위해 사용.
   • DB 초기화에도 사용
   • ex) dev, prd

To Do

1. @haxr369 현재 PR 리뷰 후 주문 서버 구현
2. @ooMia 가상 결제 서버 구현

[haxr369]

프로젝트 구현 진행 상황 공유

1. 현재 주문 서버와 결제 서버의 각 작업들의 transaction이 연동되지 않고 따로따로 존재하기 때문에 주문 중간에 에러가 발생하면 개발자가 직접 롤백 로직을 작성해야함.
   따라서 결제 서버와 주문 서버 연동을 위해 하나의 큰 transaction 필요
2. 향후 마이크로서비스 구조로 확장하기 위한 템플릿 시스템 구축 (Docker, Nginx)

To Do

1. @haxr369 분산 시스템에서 transaction을 묶을 수 있는 방법 찾기
2. @ooMia AWS Cloud 환경에 결제 서버 배포

[ooMia]

구현 내용 설명

TO DO

• 흐름도
• Spring @Transactional > ConnectionPool