MySQL은 Repeatable read를 사용

부정합이 발생하는 상황을 해결하기 위해서

시작할떄 값이 바뀌지 않는다.

예를들면 S라는 값이 1이라면 중간에 다른 트랜잭션에서 update를 한뒤에 commit를 해서 S가는 값을 2라고 바꾸어도 S라는 값이 1로 시작했던 트랜잭션에서는 계속해서 S의값은 1이다

• 종료될떄까지

스프링의 트랜잭션

1. request : 요청을 보낸다.
2. web.xml : DB연결 세션을 생성 및 트랜잭션을 시작
3. filter : 필터를 거쳐서 맞는 정보인지 확인한다.
4. Controller -> Service -> repository

• Controller을 거친뒤 Service에서 repository에 있는 요청 값을 꺼낸다.

5. 영속성 컨텍스트 : 원하는 값을 영속성 컨텍스트로 가져온다.
6. repository -> Service -> Controller

• 이후 repository를 거쳐 Service로 이동후 원하는 update를 실행한뒤 다시 Controller로 보내게 된다.

7. 이후 Controller에 들어온 값을 html 또는 Json으로 응답을 해주게 된다.

하지만 이렇게 진행되면 값이 반영이 되지 않기 떄문에
다시 Controller에서 응답을 전송하기 직전에 트랜잭션이 종료가 되면서 flush로 값을 집어넣게 되며 DB연결 세션을 종료 시킨다.

• 그후 응답을 해주게 된다.

JPA의 OSIV전략(스프링의 단점을 보완)

보통 다시 Controller에서 응답을 보낼떄 트랜잭션이 종료되지만 경로를 줄이기 위해서 Service에서 Controller로 전송을 할떄 트랜잭션을 및 영속성 컨텍스트를 종료하면 된다.

• 어차피 Service가 실행되면 값을 바꾸기 떄문에 굳이 Controller이후에 트랜잭션을 종료시킬 필요가 없다.

또한 요청에 대한 트랜잭션의 시작도 Controller에서 요청을 받은후 Service로 전송을 하게만들수 있다.

만약 이 두가지로 이렇게 수정된다면 서비스의 부하를 줄일수 있다.

하지만 이런 방법을 택하게 된다면 후에 Controller에서 정보를 호출을 할수가 없다.

• 모두 Service에서 처리를 해야한다.

이걸 좀더 추가적으로 좋게 고쳐주고자 하면 JDBC와 트랜잭션은 Service - Controller사이에서 종료 하지만
영속성 컨텍스트는 응답 - Controller사이에서 종료를 하는 방법이 있다.

• 이 방법을 하영하면 Controller에서도 DB를 수정할수가 있다.
  application.yml 에서 open-in-view: true가 이것을 의미한다.

말로는 설명이 어려우니 궁금하면 강좌를 다시 참고할것!
참고링크 : https://getinthere.tistory.com/27