79일 - @Transactional의 '전파 모드' & ACID 中 2) 고립도 설정

원자성 전파 옵션

- 위에서의 @Transactional의 내용을 / 자식에서 어떻게 처리할 것인지 옵션 처리 가능 (전파 옵션)

- 나는 위의 @Transactional 1) 쓸게 2) 안 쓸거야

 

supports

- 위에서 @Transactional 물고들어왔을 때, 지원하겠다. 

  @Transactional 물고들어왔을때는 지원하되 나 자체로는 @Transactional 안하는 것. 

  그래서 이쪽의! @Transactional 원자성은 지켜지지 않는 것 (부모단에서 안들어오면 @Transactional  안해준다는거니까)

 

requires_new

- 밖에서 @Transactional 들어와도, '나만의' @Transactional  만들겠다는 것 

- 엇박자. 

 

required (기본 디폴트 설정이 이거라고 한다.) 

- 밖에거 지원함

- 그리고 안들어왔을 경우에도 나 혼자서라도 @Transactional 만들어서 지원함

 

-> 2개 결과는 같은데 

    requires_new는 밖에거는 lock 걸리고 / 안에거대로 처리하고 / 밖에거 lock 풀고 진행.

    -> 성능이 더 떨어진다. (굳이 lock 거니까)

 

not_supported

- 지원하지 않겠다는 옵션

- 만약 @Transactional 밖에서 있었어도 lock 걸고, 내거는 @Transactional  지원하지 않게 해서 끝내는 것

 

never 

- 지원하지 않는다는 것 

-> 만약 @Transactional  들어오면 예외 발생시켜버리겠다는 것 ... ㅎㅎ

- @Transactional 들어오면 에러내겠다고 할 정도로 싫어하는 ㅎㅎ 

 

nested

- 중첩해서 하긴 하는데 ... @Transactional 존재하면! required처럼 행동하게 되는. 

 

mandatroy

- @Transactional 물고갈 경우에만 호출해서 사용하겠다. 

 

// 납득가지 않는 옵션들도 있지 ㅎㅎㅎ 

---

* 고립도 설정 * 

https://ubermensch-with.tistory.com/370

 

dirty read, nonrepeated read, phantom read 등을 발생시키지 않기 위해.

 

밑으로 갈수록 lock을 심하게 거는 것

repeatavle read가 디폴트값

 

1) read uncommited - commit 안한 것도 보게 하면 dirty read 가 발생할 수 있겠지 ~ (phenomenon, phantom도)

   (A가 작업 중이더라도 B가) 작업 중인 데이터를 읽을 수 있는 것

   근데 그게 dirty reads/phantom reads 가 될 수 있다는 것 (데이터가 A에 의해서 변경될 가능성이 높으니)

(둘 다 commit되지 않은 데이터를 읽어옴으로서 생기는 문제)  dirty reads - commit, rollback할지 모르는 데이터를 읽어온 것 phantom reads - 읽어왔더니 없는...!

2) read committed - commit된 것만 보이게 하나... phenomenon read가 발생 (다시 읽어들일 수 없는 데이터)

- 내가 읽고 있는데/내 일 아직 안 끝났는데 다른 사람이 commit해버리면(2) -> phenomenon read가 발생

 

3) repeatable read - 내가 작업하는데 lock을 거는 것. phantom read가 발생

내가 작업한 레코드 단위에 대해서는 다른 사람은 손대지 못하는것  - 근데 100개 중 내가 작업하는게 3개라면 나머지 97개는 열려져 있는 것  cf) SERIALIZABLE은 100개 다 잠구는 것

 

//

serializable : 다른 사람들이 읽지도, 쓰지도 못하게 하는. (내 작업 끝날 때까지 다들 줄 서!) 

- 고립도의 끝파왕. 성능이 정말 좋지 않다. 

 

//

 

이렇게 각각 '알맞은' 것들 설정해주면 된다. 

(실습은 프로젝트 하면서 알맞은거 집어 넣는거로 하기로~!)