트랜잭션 전파 실무예시

이 트랜잭션의 전파의 쉬운 예시는 service - repository 관계이다.

기본적으로 데이터를 하나씩 조회하는 repository에 @Transactional이 적혀있고 이것들을 사용하는 service단에도 메소드마다 @Transactional을 달아주면서 자연스럽게 트랜잭션전파를 쓰는것

여기서 어떠한 repository든 하나라도 이상이 생기면 service의 함수 전체 내용이 커밋되지않는 방식은 맞다.

다만 한가지 유의 사항

만약 두가지 repository기능중에 하나가 오류가 나더라도 그 상황을 커밋, 저장하고 싶을때(임시데이터 저장의 오류 그냥 넘기로 했을때)
이럴때 문제인것이 임시저장의 repository의 예외 발생 - service에서 catch예외처리완료 정상흐름 - 그렇지만 전체다롤백됨
이유는 예외 하나가 발생한것은 내가 잡아서 처리하더라도 전체묶음 @Transactional에서 한번 오류가 발생하면 rollbackOnly라고 트랜잭션에 기입함
예외는 처리완료해도 저 rollbackOnly마크는 계속 있기때문에 이거보고 전체 롤백
그래서 이때 repository기능중에 하나가 오류가 나더라도 그 상황을 커밋, 저장하고 싶을때(임시데이터 저장의 오류 그냥 넘기로 했을때) 는 그 오류가 난쪽에 @Transactional(~~~ = REQUIRES_NEW)옵션 적용시켜서 따로 돌아가도록 설정가능
그외에 서비스 앞단을 하나더 만들어서도 가능 여러방법있음

로그추적기예제의 필드동기화 동시성 문제

로그추적기를 만든다. 유저가 요청을 보내면 그 요청에 대한 클레스 사용을 지나갈때마다 출력하며 다시 컨트롤러단으로 돌아올때는 시간과 예외가 있다면 예외도 출력
이때 이것을 수행하는 클레스를 싱글톤으로 등록해서 사용하면 동시성 문제가 생긴다.

즉 원래 1사람의 요청을 수행하는데 총 1초가 걸린다면 또다른 사람이 1초가 지나기전에 다시 요청을하면
로그추적지 클레스가 첫번째사람의 깊이를 0,1,2 이렇게 저장하고 있다가 이것이 다시 0으로 초기화 되기전에 다른사람이 요청하면 2부터 시작해서 ,3,4 이런식으로 증가하게되는 = 싱글톤의 동시성 문제가 발생한다.