스프링 DB

자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API데이터베이스에서 자료를 쿼리하거나 업데이트하는 방법을 제공과거 : 기존에는 DB가 바뀔때마다 사용 코드도 변경하고 바뀐 DB의 사용법을 학습해야 했다JDBC : DB가 바뀌게 되면 JDBC 표준 인터페이스의 구현

bulid.gradleclass org.h2.jdbc.JdbcConnectionH2 데이터베이스 드라이버가 제공하는 H2 전용 커넥션JDBC 표준 커넥션 인터페이스인 java.sql.Connection 인터페이스를 구현한 것JDBC는 java.sql.Connection

executeQuery() 는 결과를 ResultSet 에 담아서 반환한다.ResultSetselect 쿼리의 결과가 순서대로 들어간다내부에 있는 커서( cursor )를 이동해서 다음 데이터를 조회할 수 있다rs.next() : 이것을 호출하면 커서가 다음으로 이동한

회원 리포지토리 TEST

커넥션을 새로 만드는 과정은 복잡하고 시간도 많이 소모된다이 문제를 해결하기 위해 나온 것이 커넥션 풀이다커넥션을 미리 생성해두고 사용하는 방법보통 기본값은 10개커넥션 풀에 들어 있는 커넥션은 TCP/IP로 DB와 커넥션이 연결되어 있는 상태이기 때문에 언제든지 즉시

커넥션을 획득하는 방법을 추상화 하는 인터페이스이다이 인터페이스의 핵심 기능은 커넥션 조회 하나이다대부분의 커넥션 풀은 DataSource 인터페이스를 이미 구현해두었다. 따라서 개발자는 DBCP2 커넥션 풀 , HikariCP 커넥션 풀 의 코드를 직접 의존하는 것이

커넥션을 획득할 때 마다 URL , USERNAME , PASSWORD 같은 파라미터를 계속 전달해야 한다.처음 객체를 생성할 때만 필요한 파리미터를 넘겨두고, 커넥션을 획득할 때는 단순히 dataSource.getConnection() 만 호출하면 된다.설정과 사용의

HikariCP 커넥션 풀을 사용한다. HikariDataSource 는 DataSource 인터페이스를 구현하고 있다. 커넥션 풀에서 커넥션을 생성하는 작업은 애플리케이션 실행 속도에 향을 주지 않기 위해 별도의 쓰레드에서 작동한다예)HikariConfigHikari

DataSource 의존관계 주입 외부에서 DataSource 를 주입 받아서 사용한다.DataSource 는 표준 인터페이스 이기 때문에 DriverManagerDataSource 에서 HikariDataSource 로 변경되어도 해당 코드를 변경하지 않아도 된다.(

데이터베이스의 상태를 변화시키기 해서 수행하는 작업의 단위작업단위는 많은 질의어 명령문들을 사람이 정하는 기준에 따라 정하는 것을 의미예) INSERT 후 SELECT를 한다. 이 과정이 모두 1개의 트랜잭션안에서 일어나는 일원자성(Atomicity)트랜잭션 내에서 실

사용자는 웹 애플리케이션 서버(WAS)나 DB 접근 툴 같은 클라이언트를 사용해서 데이터베이스 서버에 접근할 수 있다. 클라이언트는 데이터베이스 서버에 연결을 요청하고 커넥션을 맺게 된다. 이때 데이터베이스 서버는 내 부에 세션이라는 것을 만든다. 그리고 앞으로 해당

트랜잭션을 시작하고 수정하는 동안에는 커밋이나 롤백 전까지 다른 세션에서 해당 데이터를 수정할 수 없도록 함먼저 들어온 세션이 락을 획득하고 작업 완료 시 락을 반납하고 대기하던 그 다음 세션이 락을 받아서 작업을 수행하고 다시 락을 반납한다일정 대기시간이 지난 후에도

커넥션을 서비스에서 얻어와서 수행한다커넥션 하나를 파라미터로 전달하여 같은 트랜잭션안에서 처리되도록 한다로직 수행 중 예외 발생 시 트랜잭션 롤백을 실행한다

DB 관련 기술마다 트랜잭션을 관리하는 기능이 다르기 때문에 기술이 바뀔 때 마다 코드의 변경이 일어나게 된다예) JDBC 를 쓰다가 JPA로 바꾸면 코드 변경이 일어남이러한 문제 해결을 위해서는 트랜잭션을 인터페이스로 만들고 인터페이스를 기술들마다 인터페이스를 구현하

리소스 동기화트랜잭션을 유지하려면 트랜잭션의 시작부터 끝까지 같은 데이터베이스 커넥션을 유지해아한다스프링은 트랜잭션 동기화 매니저를 제공한다. 이것은 쓰레드 로컬( ThreadLocal )을 사용해서 커넥션을 동기화해준다. 트랜잭션 매니저는 내부에서 이 트랜잭션 동기화

트랜잭션 사용하는 로직은 트랜잭션 시작, 성공, 실패 등과 관련된 코드가 같은 패턴으로 반복이 된다템플릿 콜백 패턴을 통해서 위와 같은 문제를 해결할 수 있음스프링은 TransactionTemplate 라 는 템플릿 클래스를 제공한다.execute() : 응답 값이 있

트랜잭션 관련 처리기능과 비즈니스 로직을 분리하기 위해 프록시를 사용스프링에서는 @Transactional 애노테이션만 붙여주면 된다. 스프링의 트랜잭션 AOP는 이 애노테이션을 인식해서 트랜잭션 프록시를 적용해준다.org.springframework.transacti

스프링 부트는 데이터소스( DataSource )를 스프링 빈에 자동으로 등록한다. 자동으로 등록되는 스프링 빈 이름: dataSource참고로 개발자가 직접 데이터소스를 빈으로 등록하면 스프링 부트는 데이터소스를 자동으로 등록하지 않는다.application.prop

언체크 예외를 활용하여 처리가 불가능 예외에 대하여 무시하고 그 예외를 의존하는 문제를 해결할 수 있음언체크 예외리포지토리 인터페이스리포지토리 구현체서비스TEST

SQLException 에는 데이터베이스가 제공 하는 errorCode 라는 것이 들어있다.데이터베이스에서 어떤 문제가 발생했는지 확인할 수 있다.오류 코드를 사용할 때는 데이터베이스 메뉴얼을 확인해야 한다.errorCode를 확인하여 사용하려면 결구 SQLExcept

스프링 예외 추상화 이해

예외 던지는 부분을 변환기를 통해서 던지면 SQLException의 errorCode별 예외로 던져준다

JDBC(커넥션, PreparedStatement, 결과 등) 반복을 효과적으로 처리하는 방법이 바로 템플릿 콜백 패턴이다. 스프링은 JDBC의 반복 문제를 해결하기 위해 JdbcTemplate 이라는 템플릿을 제공한다반복코드가 제거됨

JdbcTemplate은 spring-jdbc 라이브러리에 포함되어 있는데, 이 라이브러리는 스프링으로 JDBC를 사용할 때 기본으로 사용되는 라이브러리이다별도의 설정이 필요 없음반복 문제 해결 JdbcTemplate은 템플릿 콜백 패턴을 사용해서, JDBC를 직접 사

JdbcTemplate는 DataSource가 필요하다스프링 빈으로 등록하여 사용해도 됨 template.update() INSERT , UPDATE , DELETE SQL에 사용한다. 반환 값은 int 인데, 영향 받은 로우 수를 반환한다. identity (auto

NamedParameterJdbcTemplate 사용기존 sql은 ? 을 통해 파라미터를 구분했지만 이것은 이름을 지정하여 파라미터를 구분할 수 있음SqlParameterSource객체의 속성을 매핑하여 사용MapSqlParameterSource이름을 지정하여 사용Ma

JdbcTemplate은 INSERT SQL를 직접 작성하지 않아도 되도록 SimpleJdbcInsert 라는 편리한 기능을 제공한다.withTableName : 데이터를 저장할 테이블 명을 지정한다. usingGeneratedKeyColumns : key 를 생성하는

기본적으로 test는 application.properties 설정을 사용한다test에 설정파일이 있는 경우 해당 파일이 우선순위를 갖는다src/test 에 있는 application.properties 파일이 우선순위를 가지고 실행된다이런 경우 test 파일에 DB

운영 DB와 테스트 DB를 따로 분리한다src/main (application.properties)src/test (application.properties)

테스트 후 데이터를 롤백 시킨다

기본적으로는 @Transactional는 성공적으로 수행되면 커밋을 진행한다.@Transactional 이 테스트에 있으면 스프링은 테스트를 트랜잭션 안에서 실행하고, 테스트가 끝나면 트랜잭션을 자동으로 롤백시켜 버린다!테스트 케이스의 메서드나 클래스에 @Transac

H2 데이터베이스는 자바로 개발되어 있고, JVM안에서 메모리 모드로 동작하는 특별한 기능을 제공한다. 그래서 애플리케이션을 실행할 때 H2 데이터베이스도 해당 JVM 메모리에 포함해서 함께 실행할 수 있다. DB를 애플리케이션에 내장해서 함께 실행한다고 해서 임베디드

JdbcTemplate보다 더 많은 기능을 제공하는 SQL Mapper 이다기본적으로 JdbcTemplate이 제공하는 대부분의 기능을 제공한다SQL을 XML에 편리하게 작성할 수 있고 또 동적 쿼리를 매우 편리하게 작성할 수 있다공식 사이트https://my

참고사이트https://mybatis.org/mybatis-3/ko/dynamic-sql.htmlif 조건에 따른 쿼리 출력choose (when, otherwise) 자바의 switch 구문과 유사한 구문trim (where, set) 동적 쿼리 작성 시 w

xml 대신 애노테이션에 SQL을 작성@Insert , @Update , @Delete , @Select 기능이 제공된다. 이 경우 XML에는 <select id="findById"> ~ </select> 는 제거해야 한다. 동적 SQL이 해결되지 않으므로

Test트랜잭션 호출 로그 확인(application.properties)logging.level.org.springframework.transaction.interceptor=TRACEAopUtils.isAopProxy() 선언적 트랜잭션 방식에서 스프링 트랜잭션은

Test@Transactional 의 규칙우선순위 규칙 LevelService 의 타입에 @Transactional(readOnly = true) 이 붙어있다. write() : 해당 메서드에 @Transactional(readOnly = false) 이 붙어있다. 이

트랜잭션 AOP는 기본적으로 프록시 방식의 AOP를 사용한다. @Transactional 을 적용하면 프록시 객체가 요청을 먼저 받아서 트랜잭션을 처리하고, 실제 객체를 호출해준다. 따라서 트랜잭션을 적용하려면 항상 프록시를 통해서 대상 객체(Target)을 호출해야

메서드 내부 호출 때문에 트랜잭션 프록시가 적용되지 않는 문제를 해결하기 위해 해당 메서드를 별도의 클래스로 분리하여 해결한다다른 방법들도 있지만 주로 이 방법으로 해결함(편하기 때문임)동작 클라이언트인 테스트 코드는 callService.external() 을 호출한

스프링 초기화 시점에는 트랜잭션 AOP가 적용되지 않을 수 있다.initV1() - @PostConstruct초기화 코드가 먼저 호출되고, 그 다음에 트랜잭션 AOP가 적용되기 때문에 초기화 시점에는 해당 메서드에서 트랜잭션을 획득할 수 없다.init2() - Appl

value, transactionManager 트랜잭션을 사용하려면 먼저 스프링 빈에 등록된 어떤 트랜잭션 매니저를 사용할지 알아야 한다. 생각해보면 코드로 직 접 트랜잭션을 사용할 때 분명 트랜잭션 매니저를 주입 받아서 사용했다. @Transactional 에서도 트

예외 발생시 스프링 트랜잭션 AOP는 예외의 종류에 따라 트랜잭션을 커밋하거나 롤백한다. 언체크 예외인 RuntimeException , Error 와 그 하위 예외가 발생하면 트랜잭션을 롤백한다. 체크 예외인 Exception 과 그 하위 예외가 발생하면 트랜잭션을

스프링 기본적으로 체크 예외는 비즈니스 의미가 있을 때 사용하고, 런타임(언체크) 예외는 복구 불가능한 예외로 가정한다. 체크 예외 : 비즈니스 의미가 있을 때 사용언체크 예외 : 복구 불가능한 예외체크 예외를 할용하여 비즈니스 예외를 해결NotEnoughMoneyEx

커밋, 롤백

각각의 트랜잭션이 있는 경우 각각 처리 되기 때문에 한쪽에 문제가 생겨도 별다른 문제가 없음

트랜잭션을 각각 사용하는 것이 아니라 트랜잭션이 이미 진행 중인데 여기에 추가로 트랜잭션을 추가하는 경우 기존 것을 이어받아 사용할지 별도로 만들어 사용할지를 결정하는 것을 트랜잭션 전파라고 한다기본 옵션인 REQUIRED를 기준으로 설명외부 트랜잭션이 수행중이고, 아

외부 트랜잭션이 수행중인데, 내부 트랜잭션을 추가로 수행했다. 외부 트랜잭션은 처음 수행된 트랜잭션이다. 이 경우 신규 트랜잭션( isNewTransaction=true )이 된다. 내부 트랜잭션을 시작하는 시점에는 이미 외부 트랜잭션이 진행중인 상태이다. 이 경우 내

외부 트랜잭션이 물리 트랜잭션을 시작하고 롤백하는 것을 확인할 수 있다. 내부 트랜잭션은 앞서 배운대로 직접 물리 트랜잭션에 관여하지 않는다. 결과적으로 외부 트랜잭션에서 시작한 물리 트랜잭션의 범위가 내부 트랜잭션까지 사용된다. 이후 외부 트랜잭션 이 롤백되면서 전체

외부 트랜잭션 시작 물리 트랜잭션을 시작한다. 내부 트랜잭션 시작 Participating in existing transaction 기존 트랜잭션에 참여한다. 내부 트랜잭션 롤백 Participating transaction failed - marking existi

외부 트랜잭션과 내부 트랜잭션을 완전히 분리해서 각각 별도의 물리 트랜잭션을 사용하는 방법이다. 그래서 커밋과 롤 백도 각각 별도로 이루어지게 된다.이 방법은 내부 트랜잭션에 문제가 발생해서 롤백해도, 외부 트랜잭션에는 향을 주지 않는다. 반대로 외부 트랜잭션에 문제가

실무에서는 대부분 REQUIRED 옵션을 사용한다. 그리고 아주 가끔 REQUIRES_NEW 을 사용하고, 나머지는 거의 사용하지 않는다REQUIRED 가장 많이 사용하는 기본 설정이다. 기존 트랜잭션이 없으면 생성하고, 있으면 참여한다. 트랜잭션이 필수라는 의미로 이

domainrepositorydomainrepository