이 글은 인프런 김영한님의 강의를 복습하며 작성한 글입니다 어플리케이션의 구조 프레젠테이션 계층 UI와 관련된 처리 담당 웹 요청을 받고 응답해줌. 사용자 요청을 검증 주 사용 기술 : 서블릿 / HTTP / Spring MVC 서비스 계층 비즈니스 로직을 담당 (계좌이체) 주 사용 기술 : 가급적 특정 기술에 의존하지 않고, 순수 자바 코드로 작성해야함. 데이터 접근 계층 실제 DB에 접근하는 코드 주 사용 기술 : JDBC, JPA, File, Redis, Mongo 여러 어플리케이션 구조가 있지만 가장 많이 사용하는 방법은 역할에 따라 3가지 계층으로 나누는 방법이다. 이 때 위와 같이 3개의 계층으로 나눈다. 어플리케이션의 구조 위에서 어플리케이션을 3개의 계층으로 나눈다고 했다. 이 3개의 계층..
이 글은 인프런 김영한님의 강의를 복습하며 작성한 글입니다. 비즈니스 로직 with 트랜잭션 구현 앞선 게시글에서는 "set autocommit false"를 이용해서 트랜잭션을 구현했다. 이번 포스팅에서는 실제 어플리케이션에서 어떻게 트랜잭션을 사용해 원자성이 중요한 비즈니스 로직을 구현하는지 확인해본다. 먼저 트랜잭션 없이 단순하게 계좌이체 비즈니스 로직만 구현해보자. MemberSerivce 코드 구현(비즈니스 로직) @RequiredArgsConstructor public class MemberService1 { private final MemberRepositoryV1 memberRepository; public void accountTransfer(String fromId, String toI..
이 글은 인프런 김영한님의 강의를 복습하며 작성한 글입니다. DB 조회에는 락이 필요없다. 기본적으로 SELECT 쿼리를 이용해 DB에서 데이터를 조회하는 시점에서, 세션은 DB Lock을 얻을 수 없는 상황에서도 데이터를 조회할 수 있다. 왜냐하면 데이터 조회 시에는 락이 필요없기 때문이다. 반면에 데이터를 수정할 때는 반드시 DB 락이 있는 상황에서만 가능하다. DB 조회 시 락 설정하기 데이터를 조회하는 순간에 락을 획득해야 할 때가 있다. 획득하는 순간부터 트랜잭션이 끝날 때까지 이 데이터는 다른 곳에서 건드리지 않아야할 경우, DB 조회 시 락을 설정해볼 수 있다. 왜냐하면 DB 조회 시 락을 획득하면, 데이터를 수정하는 다른 DB 세션이 락을 얻지 못하는 상황이기 때문이다. SELECT * F..
이 글은 인프런 김영한님의 강의를 복습하며 작성한 글입니다. DataBase Lock의 개념 이해 두 개의 DB 세션이 존재한다고 가정해보자. 세션 1이 A라는 행의 데이터를 수정중이고 이를 아직 커밋하지 않은 상황이다. 이 때, 세션2가 A라는 행에 접근해서 데이터를 수정하는 상황이 있다고 가정해보자. 한 마디로 설명하면, A라는 곳을 동시에 여러 세션이 수정하려고 하는 상황이다. 이러면 문제가 없을까? 문제가 있다. 데이터의 정합성이 무너진다. 가장 큰 이유 중 하나는 트랜잭션의 원자성이 무너진다는 것이다. 위의 그림을 예로 들어보자. 세션1은 A → B → C 순으로 접근해서 각각의 데이터를 수정하는 일을 한다고 가정한다. 세션1이 A의 값을 수정하고, B의 값을 수정하는 순간 세션2가 A의 값을 ..
이 게시글은 인프런 김영한님의 강의를 복습하며 작성한 글입니다. 트랜잭션과 계좌이체 앞서서 트랜잭션을 설명하며 계좌이체에 대한 이야기를 했었다. 먼저 그 내용을 간단히 한번 상기시켜본다. memberA에서 memberB에게 5000원을 이체하는 상황을 가정한다. memberA의 잔고에서 5000원을 뺀다. memberB의 잔고에서 5000원을 증가시킨다. 계좌이체를 하기 위해서는 위 두 가지 일이 진행되어야 한다고 했다. 그리고 모두 성공되어야 하나의 일로써 인정을 받는다. 하나라도 실패한다면 이 일은 실패한 일이 되고 이 일이 시작하기 전 처음으로 돌아가야한다. 트랜잭션 실습 계좌이체 정상 성공 계좌이체 문제 상황 발생 + 커밋 계좌이체 문제 상황 발생 + 롤백 이 트랜잭션 실습에서는 계좌이체와 관련된..