공부한것들을 정리하는 블로그 입니다.

보호되어 있는 글입니다.

2. isolation 트랜잭션 격리 수준. 트랜잭션이 다른 트랜잭션과 격리되어야 하는 수준을 결정한다. - 트랜잭션이란, 트랜잭션이란, 데이터베이스의 데이터를 조작하는 작업의 단위(unit of work)이다. 트랜잭션은 흔히 이론적으로 ACID 원칙을 보장해야 한다고 한다. 하지만, 실제로는 ACID 원칙은 종종 지켜지지 않는다. 왜냐하면 ACID 원칙을 strict 하게 지키려면 동시성이 매우 떨어지기 때문이다. 그렇기 때문에 DB 엔진은 ACID 원칙을 희생하여 동시성을 얻을 수 있는 방법을 제공한다. 바로 트랜잭션의 isolation level이다. isolation이 낮을수록 ACID 원칙이 지켜지지 않기에(격리성이 낮음) 문제가 생길 수 있지만, 대신 더 높은 동시성을 얻을 수 있다. 데이터..

1. propagation 트랜잭션 전파를 위한 설정이다. 트랜잭션 동작을 설정하는 데 매우 중요한 속성이다. - REQUIRED (default) — 이미 진행 중인 트랜잭션이 없으면 새로 시작하고, 진행 중인 트랜잭션이 있다면 기존 트랜잭션에 참여한다. - REQUIRES_NEW — 항상 새로운 트랜잭션을 시작한다. - MANDATORY — 이미 진행 중인 트랜잭션이 없으면 예외를 발생시키고, 진행 중인 트랜잭션이 있다면 기존 트랜잭션에 참여한다. - NESTED — 이미 진행 중인 트랜잭션(부모 트랜잭션)이 없으면 새로운 트랜잭션을 생성하고, 진행 중인 트랜잭션(부모 트랜잭션)이 있다면 중첩 트랜잭션을 만든다. (부모의 commit/rollback은 중첩에 영향을 주지만, 중첩은 부모에 영향 x) ..

스프링에서의 트랜잭션 관리 - 스프링에서의 트랜잭션 관리 ex) 은행 계좌이체 1. Global Transactions - 분산 트랜잭션(distributed transaction) 처리 : 서로 다른 데이터베이스 간에 트랜잭션이 발생 2. Local Transactions - 로컬 트랜잭션은 간단한 JDBC 연결과 같은 단일 RDBMS와 애플리케이션 사이에서 발생한다. - 개발자의 영역 - global과 local 트랜잭션 모두, 개발자가 스스로 다뤄야하는 영역이다. - ex) jdbc를 사용한다면 트랜잭션 관리 API는 JDBC, Hibernate를 사용한다면 어플리케이션 서버의 hibernate 트랜잭션 API 등등 - 스프링 프레임워크와 트랜잭션 관리 - 스프링 프레임워크는 다양한 트랜잭션 API..

보호되어 있는 글입니다.

토비의스프링3.1 2권 3장. 스프링 웹 기술과 스프링 MVC 3장. 스프링 웹 기술과 스프링 MVC 3.1 스프링의 웹 프레젠테이션 계층 기술 스프링 웹 서블릿 컨텍스트의 분리 - 루트 앱 컨텍스트 - 서블릿 앱 컨텍스트 - 스프링은 의도적으로 서블릿 웹 앱의 컨텍스트를 두 가지로 분리해놓았다. - 웹 기술에서 완전히 독립적인 비즈니스 서비스 계층과 데이터 액세스 계층을 담은 루트 앱 컨텍스트와 - 스프링 웹 기술을 기반으로 동작하는 웹 관련 빈을 담은 서블릿 앱 컨텍스트다. - 이렇게 스프링 컨텍스트를 두 가지로 분리해둔 이유는 스프링 웹 서블릿 컨텍스트를 통째로 다른 기술로 대체할 수 있도록 하기 위해서다. 3.1.1 스프링에서 사용되는 웹 프레임워크 종류 스프링 서블릿/스프링 MVC - 스프링이 ..

보호되어 있는 글입니다.

토비의스프링3.1 2권 1장. IoC 컨테이너와 DI 우선 핵심내용인 scope에 대해서 다루고 나머지 내용은 추후 작성 1.3 프로토타입과 스코프 1.3.1 프로토타입 스코프 - 스코프는 존재할 수 있는 범위를 가리키는 말이다. - 빈의 스코프는 빈 오브젝트가 만들어져 존재할 수 있는 범위다. 싱글톤 - 기본적으로 스프링의 빈은 싱글톤으로 만들어진다. - 즉, 애플리케이션 컨텍스트마다 빈 오브젝트는 한 개만 만들어진다. 빈 오브젝트의 생명주기 - 빈 오브젝트의 생명주기는 스프링 컨테이너가 관리하기 때문에 대부분 정해진 범위의 끝까지 존재한다. 싱글톤 스코프의 생명주기 - 싱글톤 스코프는 컨테이너 스코프라고 하기도 한다. 단일 컨테이너 구조에서는 컨테이너가 존재하는 범위와 싱글톤이 존재하는 범위가 일치하..

토비의스프링 9장. 스프링 프로젝트 시작하기 9.1 자바 엔터프라이즈 플랫폼과 스프링 애플리케이션 9.1.1 클라이언트와 백엔드 시스템 가장 많이 사용되는 구조는 클라이언트가 웹 브라우저이고 백엔드 시스템이 DB인 구성이다. - 간단히 'DB를 사용하는 웹 애플리케이션' 이라고 한다. - 웹 클라이언트와 DB가 사용되지 않는 시스템은 거의 없으니, 이를 스프링이 사용되는 애플리케이션의 기본구조라고 생각할 수도 있다. 그렇다고 꼭 클라이언트는 웹 브라우저여야 하며 백엔드 시스템은 DB를 이용해야 하는 것만은 아니다. - HTML을 사용하는 표준 웹 클라이언트 외에도 Flex나 X 인터넷 제품처럼 독립적으로 강력한 기능을 가진 RIA 클라이언트가 사용되기도한다. - 또는 HTTP 프로토콜을 이용해 통신하는 ..

토비의스프링 8장. 스프링이란 무엇인가 - 스프링은 무엇일까? IoC와 DI 프레임워크로 제한하기엔 스프링이 너무 다재다능하다. 8.1 스프링의 정의 스프링의 가장 잘 알려진 정의는 - 자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크 - 자바 엔터프라이즈란 JVM에서 동작하는 기업 운영에 필요한 기술들의 집합체라고 한다. 스프링의 특징들 애플리케이션 프레임워크 - 애플리케이션 프레임워크란 특정 계층이나 기술, 업무에 국한되지 않고 애플리케이션 전 영역을 포괄하는 프레임워크를 말한다. - 즉, 스프링의 목적은 AOP, DI/IoC 등 제공하는 다양한 기술에 프로그래밍 모델을 일관적으로 적용하여 각기 다른 자바 엔터프라이즈를 다룰 때 단일한 전략과 규칙으로도 편리하게 개발할 수..

토비의스프링 7장. 스프링 핵심 기술의 응용 7.1 SQL과 DAO의 분리 SQL을 Dao에서 분리하는 이유? -> 운영 중에 DB의 테이블 or 필드이름 or SQL문이 변경될 수 있는데, 그 때마다 Dao를 수정해서 다시 컴파일하기에는 무리가 있기 때문 XML 설정을 이용한 분리 - SQL을 xml설정파일의 프로퍼티 값으로 정의해서 DAO에 주입 - 스프링의 DI를 사용하여, String값을 외부에서 SQL을 분리하였다. - 매번 프로퍼티 추가하는건 굉장히 번거롭다 -> SQL을 하나의 컬렉션으로 묶는다. SQL 맵 프로퍼티 방식 - SQL을 하나의 컬렉션으로 담도록 해보자. Key에 대응되는 Value는 SQL 문장이 될 것이다. 프로퍼티를 추가하거나 하지 않고 맵 정보에만 추가해주면 된다. - S..

토비의스프링 6장. AOP 6.1 트랜잭션 코드의 분리 메서드 분리하기 - 트랜잭션의 경계를 설정하는 코드와 비즈니스 로직을 구분할 수 있다. - 그러나 트랜잭션 코드가 여전히 UserService 내부에 존재하는 것이 부담이다. DI를 이용해 트랜잭션 분리하기 - 현재 구현은 클라이언트가 UserService 클래스를 직접 참조하고 있다. 그래서 인터페이스에 의존하여 결합도를 낮추는 작업을 수행한다. - 지금 해결하고자 하는 문제는 비즈니스 로직을 담고 있는 코드와 트랜잭션 담당하는 코드를 분리하기 위함이다. - 그러기 위해 UserService를 구현한 UserServiceTx 클래스를 만든다. - 주입받는 UserService는 비즈니스 로직을 처리하는 구체 클래스고, - UserServiceTx는..

토비의스프링 5장. 서비스 추상화 5.1 사용자 레벨 관리기능 추가하기 지금까지 다루었던 DAO는 단순 DB에 저장하고 불러오는 기능만을 담당했다. 간단한 비즈니스 로직을 추가하는 것이 이 장의 목표다. ENUM - 사용자 수정기능 추가 사용자 관리 로직은 어디에 두어야 할까? - UserService 구현하기 - 유저 레벨 조작 구현하기 - 처음 가입한 회원은 BASIC 등급이어야 한다. - 코드 리팩토링 - 업그레이드 가능한지 여부를 확인하는 메서드 - 실질적 레벨 업그레이드를 수행하는 메서드 5.2 트랜잭션 서비스 추상화 원본 코드를 수정하는 것은 좋은 생각이 아니다. 대신 UserService를 상속받고, upgradeLevel을 override하여 구현하면 장애상황에서의 대응을 테스트하는 좋은 ..

토비의스프링 4장. 예외 난감한 예외처리 - 모든 예외는 적절하게 처리되던지 프로그램을 중단하여야 한다. 예외의 종류와 특징 - Error - 복구 불가능한 시스템 레벨의 문제이므로, catch로 잡아서 할 수 있는 것이 없다. - OutOfMemorryError, ThreadDeath 등이 있다. - Exception 체크 예외 - Exception을 상속하면서 RuntimeException을 상속하지 않은 예외를 말한다. - 이 예외들은 코드에서 필수적으로 try-catch-... 블록으로 다루어져야 한다. 컴파일러가 이를 체크한다. - 쉽게 말하면 코드를 아무리 잘 작성하더라도 발생할 수 있는 예외들이다. - 로우레벨에서 네트워크, 메모리 등에 원인이 있는 IOException, SQLExcepti..

#토비의 스프링 - 3장 템플릿 3. 개방 폐쇄 원칙(OCP) - 변화에 대해 유연해야 한다. - 3장에서 다룰 템플릿은 변화가 일어나지 않는 부분을 변경이 자주 일어나는 부분으로부터 독립시키는 방법이다. 3.1 다시 보는 초난감 DAO - 예외처리 - 예외가 발생하더라도, 사용완료한 리소스(DB 커넥션 같이 제한적인)를 반환하도록 해야함 try catch finally문을 통해 예외 발생에 리소스를 반환할 수 있도록 대처했다. 그러나... 3.2 변하는 것과 변하지 않는 것 - 코드가 복잡하며 중복되는 로직 발생 - 변하지 않는 부분을, 변하는 부분으로부터 분리 : 템플릿 메서드 패턴 템플릿 메서드 패턴의 적용 - 상속을 통해 기능을 확장 - 변하지 않는 부분 : 슈퍼클래스 - 변하는 부분 : 추상 메..

테스트 내가 예상하고 의도했던 대로 코드가 정확히 동작하는지 확인하는 것 동작을 통해 코드를 확신할 수 있게 하는 작업작은 단위의 테스트 테스트는 가능하면 작은 단위로 쪼개서 집중해서 할 수 있어야 한다.(관심사의 분리 원리 적용) 단위 테스트 설계하고 만든 코드가 원래 의도대로 동작하는지 확인하기 위해 작은 단위의 코드에 대해 테스트를 수행하는 것 자동수행 테스트 코드 테스트는 자동으로 수행되도록 코드로 만들어지는 것이 중요 자동수행 → 반복가능으로 이어진다. 지속적인 개선과 점진적인 개발을 위한 테스트 테스트로 검증해서 코드에 대한 확신을 가지고, 그 후에 기능을 추가하는 식으로 점진적인 개발이 가능해진다. 테스트의 효율적인 수행과 결과 관리 JUnit 프레임워크를 이용해서 테스트를 효율적으로 진행 ..

1장 오브젝트와 의존관계 1.1 초난감 DAO - DAO(Data Access Object) 는 DB 를 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 오브젝트를 말한다. - JDBC 를 이용한 등록과 조회 기능이 있는 날 것 그대로의 UserDao 클래스를 만든다. 1.2 DAO 의 분리 - 관심사의 분리(Separation of Concerns): 관심이 같은 것끼리는 하나의 객체 안으로 또는 친한 객체로 모이게 하고, 관심이 다른 것은 가능한 한 따로 떨어져서 서로 영향을 주지 않도록 분리하는 것. - 중복 코드의 메소드 추출하기 : 관심이 다른 코드가 있는 메소드에는 영향을 주지도 않을뿐더러, 관심 내용이 독립적으로 존재하므로 수정도 간단해졌다. - 상속을 통한 확장 : 클래스 계층 ..

스프링과 싱글톤 컨테이너 1. 웹 애플리케이션과 싱글톤 - 애플리케이션은 보통 여러 고객이 동시에 요청을 하는데, 각 요청에 대해 객체를 새로 생성한다면 메모리 낭비가 심하다. - 해결방안은 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다. (싱글톤 패턴) 2. 싱글톤 패턴 - 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다. - 싱글톤 패턴을 적용하면 고객의 요청이 올 때 마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있다. - 하지만 싱글톤 패턴은 다음과 같은 수 많은 문제점들을 가지고 있다. 3. 싱글톤 패턴 문제점 - 의존관계상 클라이언트가 구체 클래스에 의존한다. DIP를 위반한다. - 클라이언트가 구체 클래스에 의존해서 ..

스프링 이야기에 왜 객체 지향 이야기가 나오는가? • 스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원 • DI(Dependency Injection): 의존관계, 의존성 주입 • DI 컨테이너 제공 • 클라이언트 코드의 변경 없이 기능 확장 • 쉽게 부품을 교체하듯이 개발 정리 • 모든 설계에 역할과 구현을 분리하자. • 자동차, 공연의 예를 떠올려보자. • 애플리케이션 설계도 공연을 설계 하듯이 배역만 만들어두고, 배우는 언제든지 유연하게 변경할 수 있도록 만드는 것이 좋은 객체 지향 설계다. • 이상적으로는 모든 설계에 인터페이스를 부여하자 실무 고민 • 하지만 인터페이스를 도입하면 추상화라는 비용이 발생한다. • 기능을 확장할 가능성이 없다면, 구체 클래스를 직접 사용하고, 향후 꼭..

보호되어 있는 글입니다.