[Feature] 주문하기 결제하기#187
Conversation
…Profect-4th-IRUM/mvp-server into feature/#166-customer-order-api
There was a problem hiding this comment.
고생 많으셨습니다!
주요 이슈로는 동시성 락과 보상 처리 로직 플로우, 특히 보상 처리의 적용 시점에 대한 의문이 있는데, prepareOrder & preparePayment 메서드 관련된 부분 리뷰 확인해주시면 감사하겠습니다:)
관련하여 작업하신 @hyeonji91 @Bal1oon 두 분 외 나머지 분들도 함께 검토해보시면 좋을 것 같습니다.
일부 에러코드, 컨벤션 관련한 이슈는 해결해주시면 감사하겠습니다!
| // 재고 확인 | ||
| ProductOptionValue productOptionValue = | ||
| productOptionValueRepository | ||
| .findByIdWithLock(productReq.optionValueId()) |
There was a problem hiding this comment.
P3: 재고 동시성 문제에 대해 많이 고민하신 것 같습니다. 👍
다만 한가지 우려스러운 점은, JPA 레벨의 Lock 이 Transaction단위로 처리된다는 것입니다.
락이 유지되는 동안 타 유저들은 해당 상품 옵션에 대한 접근 자체가 불가능해진다는 것인데, 이 부분은 고려가 좀 더 필요하지 않나 싶습니다. 특히 2차 스프린트에서 서비스가 분리되면, 결제나 쿠폰 관련 서비스로부터의 응답에 생기는 지연 만큼 락의 유지 시간도 함께 연장되어 문제가 더 클 것 같습니다. 혹시 이와 관련하여 찾아보신 부분이 있다면 공유 부탁드립니다!
@Bal1oon
-> Repository 단에서 lock 유지 시간 3초로 제한해 두신 것 확인했습니다! 추후 분산 환경 처리 성능 따라 시간 조정은 검토해볼만 한 것 같네요:)
| private final ProductOptionValueRepository productOptionValueRepository; | ||
|
|
||
| /** 주문에 포함된 모든 상품의 재고를 다시 늘립니다. (보상 트랜잭션) 추후에 SAGA패턴으로 변경 가능성 있음 */ | ||
| @Transactional(propagation = Propagation.REQUIRES_NEW) |
There was a problem hiding this comment.
P5: @Transactional(propagation = Propagation.REQUIRES_NEW) 을 통해 해당 메서드가 호출된 기존 트랜잭션이 호출되어도, 별도의 트랜잭션을 새로 생성하여 진행할 수 있다고 하네요. 이를 통해 기존 요청이 롤백되어도, 분기된 트랜잭션은 독립적으로 시행될 수 있다고 하네요. preparePayment가 실패해도 재고 롤백은 이와 독립적으로 이루어지게 하기 위해 설계하신 것 같습니다.
다른 팀원분들을 위해 리뷰 중 공부한 내용 남깁니다:)
|
리뷰 감사합니다 :) |
|
모두 꼼꼼한 리뷰 감사합니다!! |
5 participants
🛠️ Issue Number
closes #166
📌 작업 내용 및 특이사항
주문하기 흐름
결제하기 흐름
📚 참고사항
TOSSPAYMENTS_SECRET_KEY env에 추가 (노션에 올려둘게요)
Payment 테이블에 tossPaymentKey, tossOrderId 필드 추가
