Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
Tags
- 브루트포스
- 구현
- DP
- Network
- JPA
- Java
- DynamicProgramming
- 백준
- 동적계획법
- 스프링
- greedy
- programmers
- DFS
- 백트래킹
- Backtracking
- 깊이우선탐색
- 이분탐색
- 네트워크
- ReactiveProgramming
- Spring
- dynamic programming
- BFS
- 우선순위큐
- 그리디
- 부분수열의합
- Algorithm
- 프로그래머스
- 알고리즘
- boj
- 너비우선탐색
Archives
- Today
- Total
목록ApplicationEventPublisher (1)
옌의 로그
[Spring] ApplicationEventPublisher에 대한 고찰 (feat. Fcm push)
FCM 푸시 모듈 작업을 계기로 마주친 이벤트 기반 설계 이야기 1. 사용하게 된 배경최근 FCM을 활용한 푸시 알림 모듈을 구현하게 되었다.초기에는 단순히 서비스 로직 안에서 푸시 메시지를 생성하고 전송하는 sendPushMessage() 메서드를 직접 호출하는 방식으로 구현했는데, 이 방식에는 치명적인.. 구조적 문제가 있었다.푸시 메시지를 생성하고 저장하는 로직이 서비스의 트랜잭션 흐름에 함께 묶여서, 이로 인해 메세지 생성 트랜잭션이 롤백되면 메인 트랜잭션도 함께 롤백되는 상황이 발생하였다.(push는 로그 데이터 같이, 생성 실패하여 발송이 안되더라도 크게 문제없는 데이터인데 이로 인해 메인로직이 처리가 안되는 건 문제가 있는 상황이다) 물론 트랜잭션 전파 속성을 REQUIRES_NEW로 설정하..
스터디/스프링
2025. 8. 8. 01:00