스프링의 전통적인 트랜잭션

• 스프링의 시작 순서

1. 톰캣 시작(서버 작동)

2. web.xml 읽기

3. context.xml 읽기 -> DB연결 테스트

 

📚 전통적인 방식

 

1. request 요청 : A가 B에게 만원 송금

2. web.xml -> 필터 -> Controller로 이동

3. 2의 과정에서,

    DB연결 세션이 생성 (JDBC가 커넥션이 되었다)

    트랜잭션 시작

4. Controller로 이동해서, 요청에 맞는 Service를 호출한다. 

5. 송금() 메소드 실행

 

💡 update 방법 ! 

 

• A, B 두 사람의 계좌를 select해서 영속성 컨텍스트에 객체화시켜 만들어둔다.
• select()된 객체를 받아와서 Service에서 값을 업데이트 시켜준다.(A는 +만원, B는 -만원) => 현재 DB에 반영되지 않았다. 영속성 컨텍스트에 있는 객체의 값만 변경되었음
• 트랜잭션을 종료시킨다. (commit) -> 자동으로 영속성 컨텍스트에 있는(즉, 값이 변경된 객체) 객체를 DB가 변경감지를 해서 flush로 넣어준다.(update 수행)
• Controller에서 response를 해준다. (with DB연결 세션 종료) => RestController는 data(JSON)로 응답, Controller라면 html로 응답

 

시점의 이동

Controller 종료 시점이 아니라, Service가 종료될때 아래 과정이 일어나도 된다.

• JDBC 커넥션 종료
• 트랜잭션 종료 -> commit -> 변경감지(update 수행)
• 영속성 컨텍스트 종료

DB 커넥션 시점이 줄고, 트랜잭션 범위가 줄기 때문에 DB에 대한 부하가 줄어든다. 

 

 

📚전통적인 트랜잭션 방식의 문제점

 

전통적인 트랜잭션 방식에서는

1. JDBC 커넥션 시작(DB에 select, insert등의 쿼리 날릴 수 있는 상태)

2. 트랜잭션 시작

3. 영속성 컨텍스트 시작

 

위의 세가지가 모두 한번에 진행된다. (request 실행 시점에)

 

 

스프링 2.0부터는 위의 그림처럼 진행된다. (영속성 컨텍스트가 끝나는 시점에 변화가 생긴다.)

영속성 컨텍스트는 Controller 전에 시작되고, Controller가 지난 뒤에 끝난다. 

=> Controller에서 지연로딩을 통해 데이터를 가져오는 것이 가능해진다. 

 

User Interface를 Controller라고 생각하면 된다!

 

트랜잭션과 JDBC 커넥션이 종료된 뒤에도, 영속성 컨텍스트가 아직 끝나지 않았기 때문에 Persistence상태를 유지하며 프록시 객체에 대한 지연로딩이 가능하다. 

세션(영속성 컨텍스트 포함)은 컨트롤러 영역까지 끌고 가기 때문에 영속성이 보장되어 select가 가능하다.

(*참고: ManyToOne의 기본 전략 : Eager)

 

open-in-view설정을 true로 하면, Lazy로딩이 가능하다. (default가 true이다)

false로 설정하면, Persistence Context 시작 시점이 Service시작시점으로 내려온다. (Lazy 로딩 불가)

Eager전략이면, DB에서 영속성 컨텍스트로 객체를 가져오는 것이 아닌 프록시(빈 객체)를 가져온다.