Spring/Spring DB

스프링 test를 이용해서 체크예외와 언체크 예외를 비교해보자 체크 예외 기본 이해 체크 예외는 잡아서 처리하거나, 또는 밖으로 던지도록 선언해야한다. 그렇지 않으면 컴파일 오류가 발생한다. @Slf4j public class CheckedTest { @Test void checked_catch() { Service service = new Service(); service.callCatch(); } /** * Exception을 상속받은 예외는 체크 예외가 된다. */ static class MyCheckedException extends Exception { public MyCheckedException(String message) { super(message); } } /** * Checked 예외..

트랜잭션 추상화 + 트랜잭션 템플릿 이 두개를 도입해서 트랜잭션을 특정 기술에 의존하지 않도록하고, 반복적인 트랜잭션 로직을 해결했다. 하지만 아직 서비스 계층에 순수한 비즈니스 로직만 남기는 것을 해결하지 못했다. → AOP를 통해 프록시를 도입하면 문제를 깔끔하게 해결할 수 있다 @Transactional 을 사용 하면 스프링이 AOP를 사용해서 트랜잭션을 편리하게 처리해준다 정도로 이해해도 된다. 프록시를 통한 문제 해결 프록시 도입 전 프록시를 도입하기 전에는 기존처럼 서비스의 로직에서 트랜잭션을 직접 시작한다 프록시 도입 후 프록시를 사용하면 트랜잭션을 처리하는 객체와 비즈니스 로직을 처리하는 서비스 객체를 명확하게 분리할 수 있다 프록시 코드 예시 public class TransactionP..

데이터소스와 트랜잭션 매니저를 직접 스프링 빈으로 등록 스프링 부트가 나오면서 많은 부분이 자동화 되었다 → 데이터소스와 트랜잭션 매니저를 자동으로 등록할 수 있게되었다 데이터소스 자동등록 스프링 부트는 데이터소스를 스프링 빈에 자동으로 등록한다. 자동으로 등록되는 스프링 빈 이름: dataSource 참고로 개발자가 직접 데이터소스를 빈으로 등록하면 스프링 부트는 데이터소스를 자동으로 등록하지 않는다. 스프링 부트가 어떻게 자동으로 등록해주나? → application.properties에 있는 속성을 사용해서 DataSource를 생성하고 스프링 빈에 등록한다. 스프링 부트가 기본으로 생성하는 데이터소스는 커넥션풀을 제공하는 HikariDataSource 이다. 커넥션풀과 관련된 설정도 applica..

트랜잭션을 사용하는 로직을 살펴보면 위 사진과 같은 패턴이 반복된다. 트랜잭션을 시작하고, 비즈니스 로직 실행하고, 성공하면 커밋, 예외가 발생해서 실패하면 롤백 다른 서비스에서 트랜잭션을 시작하려면 try, catch, finally를 포함한 성공시 커밋, 실패시 롤백 코드가 반복될 것이다. → 트랜잭션 템플릿을 적용해서 반복되는 코드를 해결해 보자 트랜잭션 템플릿 템플릿 콜백 패턴을 적용하려면 템플릿을 제공하는 클래스를 작성해야하는데, 스프링은 TransactionTemplate 라는 템플릿 클래스를 제공한다. public class TransactionTemplate { private PlatformTransactionManager transactionManager; public T execute(..

트랜잭션 추상화 현재 서비스 계층은 트랜잭션을 사용하기 위해서 JDBC 기술에 의존하고 있다. 향후 JDBC에서 JPA 같은 다른 데이터 접근 기술로 변경하면, 서비스 계층의 트랜잭션 관련 코드도 모두 함께 수정해야 한다. 트랜잭션을 사용하는 코드는 데이터 접근 기술마다 다르다 문제를 해결하려면 트랜잭션 기능을 추상화하면 된다 트랜잭션 추상화로 JDBC 구현 기술이 서비스 계층에 누수되는 문제가 해결된다 서비스는 특정 트랜잭션 기술에 직접 의존하는 것이 아니라, TxManager 라는 추상화된 인터페이스에 의존 한다. 이제 원하는 구현체를 DI를 통해서 주입하면 된다. 예를 들어서 JDBC 트랜잭션 기능이 필요하면 JdbcTxManager 를 서비스에 주입하고, JPA 트랜잭션 기능으로 변경해야 하면 J..

스프링이 제공하는 트랜잭션 매니저는 2가지 역할을 한다. 트랜잭션 추상화 리소스 동기화 리소스 동기화 트랜잭션을 유지하려면 트랜잭션의 시작부터 끝까지 같은 데이터베이스 커넥션을 유지해아한다. 스프링은 트랜잭션 동기화 매니저를 제공한다 이것은 쓰레드 로컬( ThreadLocal )을 사용해서 커넥션을 동기화해준다. 트랜잭션 매니저(트랜잭션 인터페이스)는 내부에서 이 트랜잭션 동기화 매니저를 사용한다. 트랜잭션 동기화 매니저는 쓰레드 로컬을 사용하기 때문에 멀티쓰레드 상황에 안전하게 커넥션을 동기화 할 수 있다 따라서 커넥션이 필요하면 트랜잭션 동기화 매니저를 통해 커넥션을 획득하면 된다. 리소스 동기화 동작 방식 트랜잭션을 시작하려면 커넥션이 필요한데 트랜잭션 매니저는 데이터소스를 통해 커넥션을 만들고 트..

이전에 트랜잭션을 적용하면서 서비스 계층이 복잡해지는 문제가 있었다. 먼저 애플리케이션 구조를 단순하게 나눠서 살펴보면 프레젠테이션 계층 UI와 관련된 처리 담당 웹 요청과 응답 사용자 요청을 검증 주 사용 기술: 서블릿과 HTTP 같은 웹 기술, 스프링 MVC 서비스 계층 비즈니스 로직 담당 주 사용 기술: 가급적 특정기술에 의존하지 않고, 순수 자바 코드로 작성 데이터 접근 계층 실제 데이터베이스에 접근하는 코드 주 사용 기술: JDBC, JPA, File, Mongo ... 서비스 계층을 순수하게 개발해야하는 이유 비즈니스 로직은 최대한 변경없이 유지되어야 한다.. 계층을 나눈 이유도 서비스 계층을 최대한 순수하게 유지하기 위한 목적이 크다. 기술에 종속적인 부분은 프레젠테이션 계층, 데이터 접근 ..

트랜잭션 적용 트랜잭션은 비즈니스 로직이 있는 서비스 계층에서 시작해야한다. 이유는 비즈니스 로직이 잘못되면 해당 비즈니스 로직으로 인해 문제가 되는 부분을 함께 롤백해야하기 때문이다. 트랜잭션은 세션 단위로 진행된다. 세션은 커넥션 당 하나의 세션이 부여된다. 트랜잭션을 시작하기 위해서는 커넥션이 필요하므로 결국 서비스 계층에서 커넥션 만들고, 트랜잭션 커밋 이후에 커넥션을 종료해야 한다. 애플리케이션에서 DB 커넥션을 사용하려면 트랜잭션을 사용하는 동안 같은 커넥션을 유지해야 한다. 그래야 같은 세션을 사용할 수 있다. 그럼 애플리케이션 로직에서 어떻게 같은 커넥션을 유지할 수 있을까? 커넥션을 파라미터로 전달해서 같은 커넥션이 사용되도록 하자 커넥션은 유지하기 위해 변경된 부분 1. 커넥션 유지가 ..

커넥션 풀 이해 데이터베이스 커넥션을 획득할 때는 다음과 같은 과정을 거친다. 애플리케이션 로직은 DB 드라이버를 통해 커넥션을 조회한다. DB 드라이버는 DB와 TCP/IP 커넥션을 연결한다. 물론 이 과정에서 3 way handshake 같은 TCP/IP 연결을 위한 네트워크 동작이 발생한다. DB 드라이버는 TCP/IP 커넥션이 연결되면 ID, PW와 기타 부가정보를 DB에 전달한다. DB는 ID, PW를 통해 내부 인증을 완료하고, 내부에 DB 세션을 생성한다. DB는 커넥션 생성이 완료되었다는 응답을 보낸다. DB 드라이버는 커넥션 객체를 생성해서 클라이언트에 반환한다. 이렇게 커넥션을 새로 만드는 것은 과정도 복잡하고 시간도 많이 많이 소모되는 일이다. 고객이 애플리케이션을 사용할 때, SQL..