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


 




1. 람다 없이 기본 소팅


소팅은 Collections의 소팅을 이용하며, 사용 시 익명함수를 마들어 사용한다.




2. 람다를 이용한 소팅


다음 예제는 람다를 이용하여 익명함수를 작성하는 것이다.


(추가적으로 1의 예제에서 Collections의 sort api를 사용했지만 2번에서는 List의 sort api를 사용하였다.)


3. 타입 정의 없이 사용하기


 2번예제에서 익명함수를 구현할 때 구체적인 타입을 명시해주는 부분이 있는데, 이 부분을 타입 명시 없이도 사용가능하다



4. Static 메소드를 참조하여 사용하기


 람다에서 static 메소드를 참조하는 법을 배워보자. sort함수를 static으로 작성하고 이를 참조하여 작성하면 아래와 같다.



5. 리버스 소팅


 JDK 8에서부터 역소팅을 지원한다. 

  



6. Multiple comparators


JDK8에서부터 체이닝 형식으로 다중 비교를 할 수 있도록 제공합니다.




[출처 : https://www.baeldung.com]



'Programming > JAVA' 카테고리의 다른 글

final, finally, finalize  (0) 2018.11.20
Comparison with Lambda  (0) 2018.10.29
자바 8 - Map  (0) 2018.10.19
캡슐화, 추상화, 인터페이스  (0) 2018.10.10
자바8 - List  (0) 2018.10.02
자바8 - 제네릭  (2) 2018.09.03

애플릿(Applet)


: 요청을 어플리케이션을 생성하여 그 속에서 처리하여 내린다.(멀티 프로세스 방식) -> 웹 클라이언트(브라우저)에서 돌아가는 작은 프로그램



프로세스 생성 비용



서블릿 (Servlet) 


: 요청을 서블릿 컨테이너에게 넘기고, 서블릿 컨테이너는 스레드를 이용하여 각각을 처리한다. -> 서버 측에서 돌아가는 작은 프로그램


최초의 요청에 대해서 어플리케이션 실행 후 그 뒤에는 하나로 유지(멀티 스레드 기반)


[출처 : 

http://myblog.opendocs.co.kr/archives/427

http://www.libqa.com/wiki/133]


서블릿 컨테이너와 스프링 컨테이너 -> https://minwan1.github.io/2017/10/08/2017-10-08-Spring-Container,Servlet-Container/

'Programming > JSP' 카테고리의 다른 글

애플릿 서블릿  (0) 2018.10.26
쿠키 정리 파일  (0) 2018.10.17
web.xml 설정을 통한 파라미터 인코딩  (0) 2018.01.23
[JSP] 학점 변환기  (0) 2017.09.29
톰캣 설치 후 오류 - No ouput folder  (1) 2017.09.10

https://jojoldu.tistory.com/129?category=635883 님의 Validation을 통한 유효성을 체크하는 글을 따라해보다 뭔가 느낌이 뽝 와서 적어봅니다.


일단 최조 Valid(여기서는 MemberRequestDto에 validation을 작성.)를 통해 걸러지게(?) 되면 



다음과 같은 에러를 보게 된다.


Valid를 통해서 에러를 내리는 법도 있지만, 중복 검사와 같이 어떤 작업을 거치고 에러를 내리는 것은 불가능하기 때문에 Exception을 만들고 내려야한다. 그러기 위해서는 새로운 Exception을 만들어보자.


내가 원하는 그림은 위와 같이 이메일을 중복 검사하여 중복이 되면 해당 에러를 valid에서 내린 에러와 같이 내리되 필요한 default message와 field 부분만 따로 Error클래스로 만들어 내리는 것이다.

 

코드를 보면 클래스위에 어노테이션에 해당 예외 클래스는 어떤 상태를 내릴 것인지 결정을 하고, RuntimeException을 상속받아 원하는 부분을 작성하기 시작하면 된다. 



Exception을 만들었다면 기존의 에러를 내릴 때 사용하는 클래스에 새로 만든 Exception의 에러를 추가해준 후 내려야 한다. 빈을 등록해보자


 

이렇게 기존에 getErrorAttributes에 현재 내리는 Exception종류가 ValidCustomException일 때 속성을 추가해주고 필요할 때 예외를 던지면 된다.







  • Map의 자료구조


Key / Value 형태


  • Map의 종류
  1. HashMap

    - Key, value에서 null값을 허용한다.

    - 저장된 순서를 보장하지 않는다.key값의 소팅으로 저장됨( 저장된 순서를 유지하고 싶다면 Linked를 통해 구현된 것을 이용)

    - get, put에 대하여 일정한 시간의 성능을 제공한다 -> O(1)

    - 동기화 되어 있지 않다.

    [해쉬 분포와 해쉬 충돌 : https://d2.naver.com/helloworld/831311]

  2. HashTable

    HashMap과 비슷하나 동기화 처리 되어있다(권장은 하지 않는다 concurrent된 것을 사용하자)

  3. TreeMap

    -
    블랙 레드 트리에 기초(이진 트리가 편향되지 않도록 만드는 조건이 달림)

    - 순서가 보장되지 않는다.

    - 동기화 되지 x

    - value로 null이 들어갈 수 있다.

    - 추가, 삭제에 대하여 O(log(n))

    - HashMap에 비해 메모리를 덜 잡아먹는다.










'Programming > JAVA' 카테고리의 다른 글

final, finally, finalize  (0) 2018.11.20
Comparison with Lambda  (0) 2018.10.29
자바 8 - Map  (0) 2018.10.19
캡슐화, 추상화, 인터페이스  (0) 2018.10.10
자바8 - List  (0) 2018.10.02
자바8 - 제네릭  (2) 2018.09.03

쿠키.pptx


쿠키 정리 파일입니다.

'Programming > JSP' 카테고리의 다른 글

애플릿 서블릿  (0) 2018.10.26
쿠키 정리 파일  (0) 2018.10.17
web.xml 설정을 통한 파라미터 인코딩  (0) 2018.01.23
[JSP] 학점 변환기  (0) 2017.09.29
톰캣 설치 후 오류 - No ouput folder  (1) 2017.09.10

+ Recent posts