Repeactable read
Transaction과정 중, 한번이라도 SELECT에서 다른 값이 나오면 이것을 부정합이라 한다.
Phantom read라는 것은 결과값 a가 계속 나오다가
결과가 아예 없는경우, 보였다 안보였다하는 것을 말한다.
Repeactable read로 이 문제점을해결이 가능하다.
EX)
T12번이라면 T11보다 늦게 시작한 Transaction이라고 가정하자.
T12에서 B로 값을 UPDATE했지만, 이후에도 T11은 SELECT해도 A값이나온다. T12를 아직 commit하지않았기 때문이다.
T12를 commit하면, undo의 내용이 T12가 B로 변경했다고 바뀜, 그 후 SELECT하면 B가 나오는게 Read commit이다.
Repeactable read T11이 Transaction을 종료하지 않았기 때문에 처음 SELECT한 A값이 나온다.
Repeactable read에서는 부정합이 발생하지 않는다.
T11을 SELECT할 때 자기 Transaction 순서보다 이전의 undo log를 보고 SELECT를한다.
CUD뿐만 아니라,SELECT할 때에도 도 정합성을 위해서 @Transactional을 붙인다.
Spring의 기존 Transaction
Spring을 시작하면 Tomcat이 시작됨, 서버가 작동하기위해 web.xml, context.xml 이후 db가 연결되는지 테스트를 한다.
ㄴ출처 : https://www.youtube.com/watch?v=y4a0X7dS2q8&list=PL93mKxaRDidECgjOBjPgI3Dyo8ka6Ilqm&index=46
EX) Request 송금요청, a(10000원보유)가 b(50000원 보유)에게 10000원을 송금, Request->web.xml->filter(db연결세션 이 만들어짐 : jdbc가 커넥션이 성공했다는 의미crud가능, 트랜잭션이 시작됨) -> spring컨테이너요청분기_서비스 요청(송금)_UPDATE(DB a셀렉트, b셀렉트->영속성 컨텍스트 에 계좌객제(a,b만들기)-> repository->service에서 a값 0원, b값 60000원으로 변경->요청분기(controller로 돌아감) controller에서 3.트랜잭션 종료시키기 -> 자동으로 영속성 컨텍스트에 변경되있는 계좌객체를 db에서 4변경감지를 해서, flush를 하고 db에 집어넣는다.
그 후에 ->data(json),.html으로 response(송금이 완료됨, 메인으로
돌아가는 화면 리턴해주기),그리고 5. db연결 세션이 종료된다.
UPDATE를 실행시킬 때 JPA에서는 a,b를 SELECT해서 영속성 컨텍스트에 집어넣는다.
그리고 계좌 객체의 값을 UPDATE한다.
