Spring

문제 JPA를 사용하면서 서로 다른 엔티티를 save할때 id값이 엔티티 별로 나누어지지 않고 합쳐서 올라가는 경험을 한 적이 있을 것이다. commentRepository.save(new Comment()); memberRepository.save(new Member()); 예를 들어 위의 코드를 실행하면 이렇게 엔티티별로 id가 분리되지 않고 함께 증가하는걸 알 수 있다. @GeneratedValue를 사용하면 default값으로 AUTO가 적용되고, AUTO는 IDENTITY를 기본으로 사용한다고 알고 있었는데, 실제로 적용되는 전략은 IDENTITY가 아니였던 것이다. 실제 어떤 전략이 적용되었는지 확인해보면, 사진에서 볼 수 있듯이 테이블 시퀸스가 적용된것을 알 수 있다. 테이블 시퀸스 전략이란..

Redis 인메모리 데이터이기 때문에 RDBMS에 비해 접근 속도가 빠르다. 사용방법 EC2 메모리 직접 사용 레디스 클라우드로 원격 사용 사용하기 좋은 곳 I/O 작업이 빈번한 곳 (실시간 조회수를 계속 COUNT 해야하는 서비스) 사용자 세션 관리 Springboot에 redis 간편 적용 spring: cache: type: redis redis: time-to-live: 10000 cache-null-values: true redis: host: localhost port: 6379 application.yml 설정법 @EnableCaching // 추가해주기 @EnableJpaAuditing @SpringBootApplication public class JpaToyprojectApplicati..

기본적으로 트랜젝션과 영속성 컨텍스트는 범위를 같게 한다. 순서는 → 스프링 트랜젝션 AOP 동작 → 트랜젝션 내 메서드 호출 → 트랜젝션 커밋 직전 영속성 컨텍스트 플러시 → 트랜젝션 종료 → 그 이후 엔티티는 준영속 상태 여러 쓰레드가 하나의 엔티티 매니져에 접근 할 수 있지만, 쓰레드마다 트랜젝션이 별개로 할당되기 때문에 영속성 컨텍스트도 따로 할당된다. 근데 이 상태에서는 변경 감지나 지연로딩을 사용하지 못한다. 이것들은 모두 영속성 컨텍스트가 살아있을때만 가능하다. 지연로딩은 트랜젝션과 상관없이 영속성 컨텍스트만 살아있으면 된다. 지연로딩은 즉시로딩의 N+1 문제를 해결해준다. 하지만 지연로딩 자체도 DTO로 변환할때 N+1문제를 가질 수 있다. 즉시로딩에서의 N+1 문제 과정 -> JPQL은 ..

1. 임의의 클래스를 하나 만든다. 2. RuntimeExeption을 extends 해준다 3. alt + insert 눌러서 override 클릭 4. 상단의 메서드 모두 불러온다. public class NotEnoughStockException extends RuntimeException{ public NotEnoughStockException() { super(); } public NotEnoughStockException(String message) { super(message); } public NotEnoughStockException(String message, Throwable cause) { super(message, cause); } public NotEnoughStockExcept..

SpringBootApplication이 동작하는 방식 run 메서드 안에 파라미터로 집어넣으면 스프링 빈으로 등록된다. run 메서드 내부적으로 ConfigurableApplicationContext를 생성한다. 이것이 스프링 컨테이너 자체이다. ComponentScan을 사용하려면 해당 어노테이션이 붙어있는 클래스가 스프링 빈으로 등록되야 한다. 빈을 찾으려면 따로 DL 기능을 제공하는 ObjectProvider를 사용하기 ObjectProvider로 찾아올때 객체의 생성, 의존관계 주입 및 초기화 까지는 스프링 컨테이너가 제공해준다. 그 뒤 반환하고 나면 컨테이너가 관리하지 않는다. 싱글톤 방식 정리 ComponentScan은 무조건 객체를 스프링 빈으로 싱글톤 등록해준다. 설정 정보에 @Confi..

스프링 빈은 생성부터 종료까지 일정한 생명주기를 가진다. 스프링 컨테이너 생성 -> 스프링빈 객체 생성 -> 의존 관계 주입 -> 기능 동작 -> 스프링 빈 종료 -> 프로그램 종료 스프링 빈으로 등록된 객체를 정상 사용하려면 의존 관계까지 완벽하게 주입 완료된 상태여야 한다. 만약 의존 관계 주입이 완료되지 않은 상태에서 의존 관계 주입 대상을 사용한 로직을 수행한다면 NULL 값이 뜰 수 밖에 없다. 또한 스프링 빈으로 등록된 객체에서 네트워크 소켓 연결이나 DB 연결을 사용한다면 어플리케이션 종료 시점에 커넥션을 잘 끊어줘야 자원의 낭비나 오류를 막을 수 있다. 이를 해결하려면 우리는 스프링 빈의 의존관계 주입 완료 시점과 스프링빈 종료 시점을 파악할 수 있어야 한다. 스프링에서는 이 시점들을 알려..

싱글톤 패턴 싱글톤 패턴은 애플리케이션이 시작 될 때 static을 통해 인스턴스를 메모리에 딱 하나 할당하고, 뒤의 호출 시 마다 해당 인스턴스를 반환해주는 디자인 패턴이다. 생성자를 private으로 설정하기 때문에 외부에서 생성자를 통해 인스턴스를 만들 수 없다. public class NoteBook { private static NoteBook noteBook = new NoteBook(); public static NoteBook getInstance() { return noteBook; } private NoteBook(){}; } NoteBook이라는 클래스를 간단히 싱글톤 패턴으로 구현한 코드다. 보통의 경우 생성자를 public으로 열어서 사용자가 직접 인스턴스를 생성해서 사용하도록 한..

스프링은 객체 지향의 SOLID 원칙을 지키기 위해 어플리케이션을 동작 시키는 사용 영역과, 각 객체들의 생성과 의존관계 주입을 책임지는 구성 영역으로 코드를 분리 시킵니다. 단순 자바코드로 config 클래스를 만든 후 사용 영역에 주입할 수도 있지만 스프링은 어노테이션 기반으로 사용할 수 있는 스프링 컨테이너와 스프링 빈을 제공합니다. 스프링 컨테이너 생성 스프링 컨테이너는 ApplicationContext 라는 인터페이스를 통해 사용할 수 있습니다. ApplicationContext ac = new AnnotationConfigApplicationContext(); 코드를 보면 ApplicationContext의 실제 구현체로는 AnnotationConfigApplicationContext 가 들어..