ACID



Atomicity : 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장.

Consistency : 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지.

Isolation : 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것.

Durabillity : 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함.


특히 격리성과 관련된 문제점들 중 대표적인 3가지가 아래에 있다.



리성 관련 문제점



(1) Dirty Read : 다른 트랜잭션이 커밋되지 않은 변경된 데이터를 읽게되고, 변경된 데이터가 롤백으로 인해 변경 전으로 돌아갔지만, 이미 다른 트랜잭션이 변경된 데이터를 읽게 된 것.


(2) Non-Repeatable Read : 트랜잭션 중간에 READ된 데이터에 대해 다른 트랜잭션이 중간에 끼어들어 값을 변경하고 커밋하였을 경우, 다시 READ했을 때 변경된 데이터가 나오게 되는 것.


(3) Phantom Read : 2번과 비슷해보이지만 추가적으로 값이 변경되는 경우가 아닌 컬럼 하나가 삭제 되거나 추가되는 수준.




Trancsaction Isolation Level



이러한 고립성(Isolation) 문제점들에 대해 데이터베이스에서는 4가지의 격리 레벨을 가지고 있다. 각각은 다음과 같다.


  • READ UNCOMMITED
  • READ COMMITTED
  • REPEATABLE READ
  • SERIALIZABLE

가장 위에서부터 설명하겠다.

1. READ UNCOMMITED : 두 개의 트랜잭션이 있을 때, 하나의 트랜잭션(T1)이 커밋하지 않은 변경된 데이터에 대해 다른 트랜잭션(T2)이 접근이 가능하다.이 때 T1이 롤백을 발생시킨다면 디비에 들어있는 실 정보와 T2가 방금전에 검색했던 값은 일치하지 않을 것이다.



2. READ COMMITED : 트랜잭션(T1)이 데이터를 READ하였고 UPDATE하였을 때, 다른 트랜잭션(T2)가 READ하면 T1가 변경하기 전인 데이터를 읽어온다. T1이 commit을 마쳤을 때 T2는 비로소 변경된 데이터를 읽을 수 있다.

3.REPEATABLE READ : 트랜잭션 내에서 한번 조회한 데이터를 반복해서 조회해도 같은 데이터가 조회 된다


4. SERIALIZABLE : 트랜잭션이 완료될 때까지 READ에 사용된 모든 데이터가 락이 거려 다른 트랜잭션이 수정 및 입력이 불가능하다




[출처 : https://lng1982.tistory.com/287http://feco.tistory.com/45]

스프링 MVC 기본 흐름과 주요 컴포넌트



스프링 MVC는 여러 가지의 컴포넌트로 구성되어 있으며 흐름은 다음과 같고 역할은 밑에 표로 정리하였다.



 구성 요소

설명 

 DispatcherServlet

요청 받음, 컨트롤러에게 요청 전달, 결과값을 view에 전달한다. 

HandlerMapping

URL을 통해 어떤 컨트롤러가 이를 처리할지를 결정

 HandlerAdapter

요청을 변환하여 컨트롤러에게 전달. 컨트롤러로부터 받은 결과를 다시 리턴. 웹 브라우저 캐시 등의 설정도 담당 

Controller 

전달 받은 요청을 처리한 뒤, 결과 리턴. View에 보여줄 데이터들을 모델에 담아 전달 

 ViewResolver

뷰를 결정한다. 

View

데이터들을 Html에 삽입 


[참고 자료 : 웹 개발자를 위한 Spring 4.0 프로그래밍 - 최범균]



1. 의존 객체를 직접 생성하는 방식



아래와 같은 객체를 생성해야 한다는 가정을 들어보자.


new A( new B);


이렇게 의존 객체를 직접 생성하는 방식을 사용하게 되었을 때 내용은 아래 사진과 같이 되게 된다.




이렇게 구성되어 있을 때 만약 A가 생성할 때 B가 아닌 C를 참조해야 한다고 할 때, 다음과 같이 작성했던 모든 클래스들에 대해서 코드를 고쳐야 하는 상황이 온다.




2. 의존 객체를 외부에서 조립하여 내리는 방식



의존 객체를 직접 생성하는 방식과 달리 Dependency Injection는 의존 객체를 외부로부터 전달받는 구현 방식이다.



이 경우 A가 B가 아닌 C를 참조하게 되었을 때는 이를 정의하고 있는 파일만 고쳐주게 되면 된다는 것이다.



지금 설명할 때에는 3개의 클래스만 영향을 받기 때문에 직접 구현하는 것도 나쁘지 않다 생각할 수 있지만, 이를 몇 십개 이상의 파일을 직접 찾아 고친다고 생각하고 다시 한번 생각해보자. 

ASM ClassReader failed to parse class file - probably due to a new Java class file version that isn't supported yet:




대충 에러 내용이 ASM ClassReader가 버전이 달라서 읽을 수 없다고 하는 내용입니다.


람다를 사용하기 위해 1.8로 변경했는데 Spring의 버전이 낮아서 생긴 에러입니다.


출처 : https://spring.io/blog/2014/03/27/spring-framework-4-0-3-released-with-java-8-support-now-production-ready

스프링이란?



스프링이란?

=자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크.


정의)


프레임워크 = 소프트웨어를 만드는 데 기본이 되는 골격 코드, 완전한 애플리케이션이 아니며 확장 또는 구현하여 완전한 애플리케이션으로 완성이 된다.  예시 ) EJB , Spring


스프링의 주요 전략


1. POJO를 이용한 가볍고 비침투적 개발

2. DI와 인터페이스 지향을 통한 느슨한 결합도

3. Aspect와 공통 규약을 통한 프로그래밍

4. Aspect와 템플릿을 통한 반복적이고 상투적인 코드 제거


핵심은 응집도를 높이고 결합도를 낮추는 것.


스프링 배우기 전 개념들


1. EJB (Enterprise Java Bean)


자바빈 ?

=  컴포넌트 기반의 소프트웨어 모델 스펙, 자바 객체를 재사용 가능하게 컴포넌트화 시킬 수 있는 코딩 방침을 정의. 


엔터프라이즈 자바 빈 ?

=  보안 , 트랜잭션 지원, 분산 컴퓨팅 등의 엔터프라이즈 어플리케이션 개발 시 필요한 다양한 서비스를 컨테이너에서 제공하며 개발자는  비즈니스 로직에 전념하도록 지원. 하지만 스펙 자체가 복잡하여 사용하기 힘들고, EJB 컨테이너가 없을 경우 사용이 불가능하며, 컨테이너가 변경될 경우 호환이 어렵다는 단점이 있음.



2. POJO

어떠한 제한에도 묶이지 않은 단순 자바 오브젝트





Spring Container




Container = EJB의 비즈니스 서비스 컨테이너의 기능은 유지하되 복잡성을 제거하고 객체들의 라이프사이클을 관리


1. Spring Container


- Spring Framework에서 Container 기능을 제공

- Spring Framework를 초기화 하는 역할

- XML에 등록된 Bean들의 라이프 사이클/ 의존 관리 담당



2. Inversion of Control/Dependency Injection (제어 역전/ 의존 주입)

 

IoC = 프로그램 코드에서 직접 객체를 생성하지 않고, 외부(컨테이너)에서 빈(Bean)을 생성하고 제공한다는 개념.


IoC의 구현 방법 2가지

  1. Dependency Lookup (DL)
    DL는 클라이언트가 컨테이너에서 생성한 객체를 검색하여 사용하는 방식

  2. Dependency Injection (DI)
    DI는 컨테이너가 자동으로 처리 수행

DL의 경우 Lookup을 하기 위한 코드를 구현해야 되지만, DI의 경우 컨테이너가 직접 Lookup을 수행하므로 DL만큼의 코드를 필요로 하지 않는다.



AOP(Aspect Oriented Programming) - 관점 지향 프로그래밍


코드에서 핵심 로직(비즈니스 로직)과 그 외의 로직(공통 관심 사항)을 분리시키고, 공통 관심 사항을 구현한 코드를 핵심 로직을 구현한 코드 안에 삽입하는 것이다.


공통 기능이란 주로 트랜잭션 적용이나 보안 검사, 로그를 남기는 것과 같은 코드를 말한다.


아래와 같이 공통 기능들이 있을 때 코드는 다음과 같이 만들어질 것이다. 이렇게 되면 핵심 로직외에도 많은 코드들이 들어가야 할테고, 공통 로직에 변경이 생기면 이를 구현하고 있는 많은 클래스에서 변경이 일어날 것이다.



이를 aop의 개념으로 이용하면 다음과 같이 핵심 로직과 공통 기능을 분리시킬 수 있으며, 이를 변경함에도 쉽고, 쉽게 로직에 추가할 수도 있다. 


 




+ Recent posts