일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
- Docker
- 우아한세미나
- JPA
- 미션
- REDIS
- Paging
- 백준
- mock
- 세션
- 서블릿
- AOP
- 프로그래머스
- 스프링부트
- AWS
- 코드리뷰
- JUnit5
- Level2
- Spring Batch
- yml
- 자바
- 스프링 부트
- 레벨2
- 의존성
- 트랜잭션
- 우아한테크코스
- 프리코스
- CircuitBreaker
- HTTP
- MSA
- 우테코
- Today
- Total
목록이벤트 (2)
늘

일반적으로 분산 시스템에서 메시지를 주고받는 방법으로는 크게 2가지가 있다. API를 통한 통신 즉각적인 요청과 응답을 주고받는다. 간단한 개발 메시지 큐를 통한 통신 비동기, 배치 처리와 함께 적용하기 좋다. 일반적으로 publisher가 데이터를 큐에 넣으면 consumer가 큐에서 데이터를 꺼내서 데이터를 가공한다. 복잡한 개발 분산 시스템에서는 모든 데이터가 네트워크를 타면서 이동하므로 지연, 유실 등의 문제가 발생할 수 있다. 따라서 아래의 3가지 방식을 통해 데이터 전달을 보장하는 방법이 있다. 1. At most once producer가 최대 한 번만 송신하고 consumer가 최대 한 번만 수신한다. 간단한 구현 & 개발이지만 데이터 유실 가능성이 높다. 대용량 메세지 전송할 때 편하다...

스프링의 application context는 Application Event를 제공해준다. 해당 이벤트를 사용할 때 기존 트랜잭션에서 커밋이 된 후에 이벤트를 처리할 때, Transaction의 Propagation을 Requires_new 나 @Asnyc로 주지 않으면 같은 트랜잭션으로 묶여서 정상적으로 이벤트가 발급되지 않는다. 따라서 이벤트에 Propagation.REQUIRES_NEW 옵션을 주어서 사용했는데 이때 Requires_new를 사용한다고 해도 상위 트랜잭션에서 예외를 잡아주지 않으면 예외가 전파되어서 상위 트랜잭션도 롤백이 된다. 따라서 try-catch로 잡아줘야 한다. 그런데.. 실제 event에 대해서 예외 테스트를 진행해줬는데 try-catch로 잡지 않아도 예외가 전파되지 ..