필기노트

1. 단일 트랜잭션 - 트랜잭션 하나만 사용하기회원 리포지토리와 로그 리포지토리를 하나의 트랜잭션으로 묶는 가장 간단한 방법은 이 둘을 호출하는 회원 서비스에만 트랜잭션을 사용하는 것이다.이렇게 하면 MemberService를 시작할 때 부터 종료할 때 까지의 모든 로직을 하나의 트랜잭션으로 묶을 수 있다. 물론 MemberService가 MemberRepository, LogRepository를 호출하므로 이 로직들은 같은 트랜잭션을 사용한다.MemberService만 트랜잭션을 처리하기 때문에 앞서 배운 논리 트랜잭션, 물리 트랜잭션, 외부 트랜잭션, 내부 트랜잭션, rollbackOnly, 신규 트랜잭션, 트랜잭션 전파와 같은 복잡한 것을 고민할 필요가 없다. 아주 단순하고 깔끔하게 트랜잭션을 묶을..

목차 1. JPA, Querydsl 설정 2. Item - ORM 매핑 3. ItemRepositoryV2 (스프링 데이터 JPA) 4. ItemQueryRepositoryV2 (Querydsl) 5. ItemServiceV2 6. V2Config 7. 예외 변환 1. JPA, Querydsl 설정 1) build.gradle plugins { id 'org.springframework.boot' version '2.6.5' id 'io.spring.dependency-management' version '1.0.11.RELEASE' id 'java' } group = 'com.example' version = '0.0.1-SNAPSHOT' sourceCompatibility = '11' ext["hib..

요구사항 상품을 관리 (상품 이름 , 첨부파일 하나, 이미지 파일 여러개) 첨부파일을 업로드 다운로드 할 수 있다. 업로드한 이미지를 웹 브라우저에서 확인할 수 있다. Item - 상품 도메인 package hello.upload.domain; @Data public class Item { private Long id; private String itemName; private UploadFile attachFile; private List imageFiles; } ItemRepository - 상품 리포지토리 package hello.upload.domain; import org.springframework.stereotype.Repository; import java.util.HashMap; impo..

목차 1. 예외 계층 2. 예외 기본 규칙 3. 체크 예외 기본 이해 4. 언체크 예외 기본 이해 5. 체크 예외 활용 6. 언체크 예외 활용 7. 예외 포함과 스택 트레이스 1. 예외 계층 Object : 예외도 객체이다. 모든 객체의 최상위 부모는 Object이므로 예외의 최상위 부모도 Object이다. Throwable : 최상위 예외이다. 하위에 Exception과 Error가 있다. Error : 메모리 부족이나 심각한 시스템 오류와 같이 애플리케이션에서 복구 불가능한 시스템 예외이다. 애플리케이션 개발자는 이 예외를 잡으려고 해서는 안된다. 상위 예외를 catch로 잡으면 그 하위 예외까지 함께 잡는다. 따라서 애플리케이션 로직에서는 Throwable 예외도 잡으면 안되는데, 앞서 이야기한 E..

목록1. 트랜잭션 AOP 적용2. 스프링 부트의 자동 리소스 등록3. 트랜잭션 AOP 적용 전체 흐름4. 트랜잭션 AOP 주의 사항 - 프록시 내부 호출5. 예외와 트랜잭션 커밋, 롤백 - 기본6. 예외와 트랜잭션 커밋, 롤백 - 활용1. 트랜잭션 AOP 적용@Transactional을 사용하면 스프링이 AOP를 사용해서 트랜잭션을 편리하게 처리해준다.개발자는 트랜잭션 처리가 필요한 곳에 @Transactional 애노테이션만 붙여주면 된다. 스프링의 트랜잭션 AOP는 이 애노테이션을 인식해서 트랜잭션 프록시를 적용해준다.@Slf4j@RequiredArgsConstructorpublic class MemberServiceV3_3 { private final MemberRepositoryV3 ..

1. 비즈니스 로직과 트랜잭션(Service) 트랜잭션은 비즈니스 로직이 있는 서비스 계층에서 시작해야 한다. 비즈니스 로직이 잘못되면 해당 비즈니스 로직 으로 인해 문제가 되는 부분을 함께 롤백해야 하기 때문이다. 그런데 트랜잭션을 시작하려면 커넥션이 필요하다. 결국 서비스 계층에서 커넥션을 만들고, 트랜잭션 커밋 이후에 커넥션을 종료해야 한다. 애플리케이션에서 DB 트랜잭션을 사용하려면 트랜잭션을 사용하는 동안 같은 커넥션을 유지해야한다. 그래야 같 은 세션을 사용할 수 있다. 2. 커넥션과 세션(Repository) 애플리케이션에서 같은 커넥션을 유지하려면 어떻게 해야할까? 가장 단순한 방법은 커넥션을 파라미터로 전달해서 같은 커넥션이 사용되도록 유지하는 것이다. 3. Service 트랜잭션 적용 ..

1. 커넥션 풀 이해 1) 데이터베이스 커넥션을 매번 획득 커넥션을 새로 만드는 것은 과정도 복잡하고 시간도 많이 많이 소모되는 일이다. 이런 문제를 한번에 해결하는 아이디어가 바로 커넥션을 미리 생성해두고 사용하는 커넥션 풀이라는 방법이다. 2) 커넥션 풀 초기화와 연결 상태 애플리케이션을 시작하는 시점에 커넥션 풀은 필요한 만큼 커넥션을 미리 확보해서 풀에 보관한다. 기본값은 보통 10개이다. 실무에서는 항상 기본으로 사용한다. 커넥션 풀에 들어 있는 커넥션은 TCP/IP로 DB와 커넥션이 연결되어 있는 상태이기 때문에 언제든지 즉시 SQL을 DB에 전달할 수 있다. 3) 커넥션 풀 사용 애플리케이션 로직에서 이제는 DB 드라이버를 통해서 새로운 커넥션을 획득하는 것이 아니다. 이제는 커넥션 풀을 통..

1. JDBC 표준 인터페이스 JDBC(Java Database Connectivity)는 자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API다. JDBC 는 데이터베이스에서 자료를 쿼리하거나 업데이트하는 방법을 제공한다. - 위키백과 대표적으로 다음 3가지 기능을 표준 인터페이스로 정의해서 제공한다. java.sql.Connection - 연결 java.sql.Statement - SQL을 담은 내용 java.sql.ResultSet - SQL 요청 응답 자바는 이렇게 표준 인터페이스를 정의해두었다. 이제부터 개발자는 이 표준 인터페이스만 사용해서 개발하면 된다. 그런데 인터페이스만 있다고해서 기능이 동작하지는 않는다. 이 JDBC 인터페이스를 각각의 DB 벤더(회사)에서 자신 의 DB에 맞도록..

1. API 오류 API는 각 시스템 마다 응답의 모양도 다르고, 스펙도 모두 다르다. 예외 상황에 단순히 오류 화면을 보여주는 것이 아니라, 예외에 따라서 각각 다른 데이터를 출력해야 할 수도 있다. 그리고 같은 예외라고 해도 어떤 컨트롤러에서 발생했는가에 따라서 다른 예외 응답을 내려주어야 할 수 있다. 한마디로 매우 세밀한 제어가 필요하다. 결국 지금까지 살펴본 BasicErrorController 를 사용하거나 HandlerExceptionResolver 를 직접 구현하는 방식으로 API 예외를 다루기는 쉽지 않다. 스프링은 API 예외 처리 문제를 해결하기 위해 @ExceptionHandler 라는 애노테이션을 사용하는 매우 편리한 예외 처리 기능을 제공하는데, 실무에서 API 예외 처리는 대부..

1. 서블릿 예외 처리 웹 애플리케이션은 사용자 요청별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다. 애플리케이션에서 예외가 발생했는데, 어디선가 try ~ catch로 예외를 잡아서 처리하면 아무런 문제가 없다. 그런데 만약에 애플리케이션에서 예외를 잡지 못하고, 서블릿 밖으로 까지 예외가 전달되면 어떻게 동작할까? 1. 정상 요청 WAS(/error-ex, dispatchType=REQUEST) -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러 2. 예외발생 WAS(여기까지 전파) 컨트롤러(/error-page/500) -> View WAS는 오류 페이지 경로를 찾아서 내부에서 오류 페이지를 호출한다. 이때 오류 페이지 경로로 필터, 서블릿, 인터셉터, 컨트롤러가 모두 다시 호출된다..