Spring DB

이번 시리즈는 예외 처리에 대해 쓸 예정이다.이전까지의 코드 복기먼저, 이전에 트랜잭션 추상화 + 트랜잭션 템플릿 = 트랜잭션 AOP 프록시를 통해 서비스 계층의 코드에서 최대한 외부 기술에 대한 종속성을 제거 하고, 순수한 비즈니스 로직만 남기려고 노력했다.그 결과는 다음과 같은데, 종속성을 판단할 때는 import문을 보면 큰 도움이 된다.package hello.jdbc.service;import hello.jdbc.domain.Member;import hello.jdbc.repository.MemberRepositoryV3;import lombok.extern.slf4j.Slf4j;import org.springframework.transaction.annotation.Transactional;i..

트랜잭션 AOP가 어떤식으로 작동되는지 흐름을 정리해보자트랜잭션 AOP의 흐름1. 스프링이 @Transactional 에노테이션을 만나면, AOP 프록시를 적용해야 하는 대상인지 판별 후에 true면 프록시 생성2. Service에 대한 의존 관계는 실제 서비스가 아닌 서비스를 상속받은 AOP 프록시로 주입 받음3. Service의 메서드 실행시 프록시가 호출되고 트랜잭션 매니저를 통해 시작 (컨테이너에 등록된 트랜잭션 매니저는 자동으로 찾아옴).4. 트랜잭션 매니저가 데이터 소스를 통해 커넥션을 만들고, 트랜잭션을 시작하고 커넥션을 동기화 매니저에 보관5. 이후 프록시가 트랜잭션이 시작되면 실제 서비스 bizLogic() 을 호출하고, 비즈니스 로직은 레포지토리의 메서드를 호출7. 레포지토리는 반드시 ..

이전에 비즈니스 로직 트랜잭션 로직의 완전한 분리를 위해 트랜잭션 프록시를 사용하자고 했다.트랜잭션 프록시를 사용하기 위한 방법으로는 @Transactional이 있다고도 이야기 했다.실제로 어떤식으로 AOP을 적용하는지 코드로 보자.AOP 적용package hello.jdbc.service;import hello.jdbc.domain.Member;import hello.jdbc.repository.MemberRepositoryV3;import lombok.extern.slf4j.Slf4j;import org.springframework.transaction.annotation.Transactional;import java.sql.SQLException;/** * 트랜잭션 - @Transactional..

이전까진 Service 코드 내부에서 비즈니스 로직 + 트랜잭션을 위한 코드가 모두 존재하였다.하지만 이전부터 강조한 것 처럼, 서비스 계층에 순수한 비즈니스 로직만 존재하는 것이 유지보수에 용이하다.이전에는 서비스 계층에 트랜잭션 코드가 섞여 있었기에, 서비스 로직에서 트랜잭션을 직접 시작했다. public void accountTransfer(String fromId, String toId, int money) throws SQLException { TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition()); try { // 비즈니스 로직 수행..

트랜잭션 절차 국룰우리가 흔히 트랜잭션을 사용할때 3가지 절차를 따랐다. 코드로 보자.public void accountTransfer(String fromId, String toId, int money) throws SQLException { // 트랜잭션 시작 - 서비스는 트랜잭션 매니저만 의존한다. TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition()); try { // 비즈니스 로직 수행 bizLogic(fromId, toId, money); transactionManager.commit(status); } catch (E..

트랜잭션 시작1. 먼저 서비스 계층에서 transactionManager.getTransaction() 를 통해 트랜잭션을 시작한다.2. 이후 트랜잭션 매니저는 내부에서 데이터 소스를 이용하여 커넥션을 획득하고, setAutoCommit(false) 를 실행시켜 트랜잭션을 시작한다.3. 커넥션 동기화를 위해 동기화 매니저에 해당 커넥션을 보관한다.4. 쓰레드로컬에 커넥션을 보관함으로써 멀티 스레드 상황에 안전하게 보관이 가능하다.bizLogic 실행 1. 트랜잭션을 시작하고 bizLogic을 실행한다. Service 는 대부분 Repository에 명령을 위임하기 때문에, 레포지토리의 메서드들이 호출되고, 이때 커넥션이 필요하다면 동기화 매니저에서 커넥션을 가져다 쓴다.2. 동기화 매니저에서 커넥션을 가..

이전 글들의 매커니즘을 사용하여 코드를 리팩토링 해보자. [Spring DB] Transaction 적용 1.5 - 순수한 비즈니스 로직Application 근본 구조애플리케이션 구조중 가장 대중적인 구조는 프레젠테이션 - 서비스 -데이터 접근 계층 구조이다.각 계층의 역할을 요약하자면,프레젠테이션 - UI 담당, 웹 요청 / 응답 , 서블릿bdisappointed.tistory.com [Spring DB] 트랜잭션 추상화 - PlatformTransactionManager트랜잭션 추상화가 필요한 이유서비스에서 트랜잭션을 시작할 때 각 DB마다 구현 기술이 다르다. 예를들면 트랜잭션을 시작하는 방법이 기술별로 다 다르다.JDBC : connection.setAutoCommit(false)JPA : tr..

이전까지 소개한 스프링 트랜잭션 매니저는 2가지 역할을 한다 -> 트랜잭션 추상화 + 리소스 동기화 (커넥션 유지)트랜잭션 동기화가 필요한 이유트랜잭션을 유지하려면 트랜잭션의 시작과 끝까지 일정한 데이터베이스 커넥션을 유지해야한다.그래서 이전에 커넥션을 얻고, 그 커넥션을 파라미터로 넘기며 그 커넥션을 유지했었다. 하지만 파라미터로 커넥션을 넘기는 방법은 코드가 지저분해지고, 커넥션을 넘기는 메서드를 추가로 만들어야한다는점에서 굉장히 복잡하다.이 문제를 해결하기 위해 하나의 트랜잭션을 하나의 커넥션으로 동기화 시켜줄 어떠한 매커니즘이 필요하다.트랜잭션 동기화 매니저스프링은 트랜잭션 동기화 매니저 (TransactionSynchronizationManager)를 제공하는데, 쓰레드 로컬이라는 기술을 통해 ..

트랜잭션 추상화가 필요한 이유서비스에서 트랜잭션을 시작할 때 각 DB마다 구현 기술이 다르다. 예를들면 트랜잭션을 시작하는 방법이 기술별로 다 다르다.JDBC : connection.setAutoCommit(false)JPA : transaction.begin()이 외에도 트랜잭션을 사용하는 코드가 접근 기술마다 다르다. 그렇게 때문에 만약 데이터 접근 기술을 JDBC에서 JPA로 넘어가면 해당 코드들을 모든 프로젝트에서 수정해야한다.그림으로 쉽게 생각하면, Service와 Repository가 모두 JDBC 기술을 의존하다가 만약 JPA로 변경되게 되면 어떻게 될까?서비스에서 사용하는 모든 데이터 접근 기술 코드를 같이 변경해야한다.즉, SRP -> 단일 책임 원칙이 깨지게 된다(변경 포인트가 하나인데..