이 게시물은 원글을 읽고 정리한 글이며 원글을 읽어보는 걸 강력하게 추천드립니다 !
이전 글에서 전통적인 OSIV 패턴 개념과 단점에 대해 알아봤다.
이번 글에서는 Spring이 전통적인 OSIV 패턴의 단점을 어떻게 보완하였는지에 대해 알아본다.
Spring 프레임워크에서는 추가적인 작업 없이
전통적인 OSIV와 비슷한 메커니즘을 제공하며
OSIV 패턴의 장점을 취할 수 있는
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter 클래스를 제공한다.
그리고 전통적인 OSIV의 단점을 보완하고자 2가지 요소에 대한 고민이 있었다.
트랜잭션의 유효 범위
JDBC 커넥션의 유효 범위
이 글은 운영체제 공룡책 강의를 듣고 정리한 내용입니다.
fork( ) 시스템 콜 명령어를 사용하여
부모 프로세스로부터 자식 프로세스를 생성한다.
공통점
차이점
부모 프로세스의 pid != 0
자식 프로세스의 pid == 0
이 게시물은 원글을 읽고 정리한 글이며 원글을 읽어보는 걸 강력하게 추천드립니다 !
OSIV를 구현하는 전통적인 방법은 서블릿 필터를 사용하는 것이다.
서블릿 필터를 사용하는 OSIV 패턴의 경우 다음과 같은 과정으로 동작한다.
요청이 필터로 도착
Session 오픈 (= 영속성 컨텍스트 준비)
DB 트랜잭션 시작
컨트롤러에게 요청 위임
처리 후 View 렌더링
필터로 복귀
트랜잭션 커밋 && JDBC 커넥션 반환 && 영속성 컨텍스트 Flush
만약 위 과정에서 예외 발생 시 트랜잭션을 롤백 후 Session 종료
필터 시작 시점 : Session 오픈(= 영속성 컨텍스트 준비), 트랜잭션 시작
필터 종료 시점 : Session 닫기(= 영속성 컨텍스트 닫기), 트랜잭션 커밋, 영속성 컨텍스트 Flush, 영속성 컨텍스트 상태 전이
이 글은 운영체제 공룡책 강의를 듣고 정리한 내용입니다.
CPU가 1개가 아니라 여러 개다.
즉 registers와 cache를
독립적으로 가진 CPU가 1개의 메모리에 연결이 되어있다.
예를 들어 슈퍼 컴퓨터에는 CPU가 900만 장이 있다.
ref : 19:00
이 게시물은 원글을 읽고 정리한 글이며 원글을 읽어보는 걸 강력하게 추천드립니다 !
일반적으로 Transaction이 Commit될 때
Session의 모든 변경사항이 DB로 Flush가 이뤄진다.
하지만 영속성 컨텍스트의 Flush 시점 역시 커스터 마이징이 가능하다.
기본적으로 Hibernate는 다음과 같은 경우에 Session의 변경사항을 DB에 Flush한다.