Spring (9) 썸네일형 리스트형 @Transactional(readOnly=true) 스프링에서 조회용 메서드에 @Transactional(readOnly=true)를 사용했다. @Transactional(readOnly=true)의 이점은 무엇일까? 조회한 데이터가 의도치 않게 변경되는 일을 방지할 수 있다. JPA의 변경감지 작업을 수행하지 않기 때문에 스냅샷을 따로 보관하지 않아도 되고, 메모리를 절약할 수 있다. 데이터베이스 구조가 Master - Slave로 구성되어 있을 경우, readOnly=true는 읽기 전용으로 Slave를 호출한다. 따라서 DB 서버의 부하를 줄일 수 있다. 코드의 가독성을 높혀준다. 코드를 접하는 사람들이 직관적으로 해당 메서드가 Read에 대한 동작만 수행할 것이라고 예상할 수 있다. [JPA] OSIV OSIV는 Open Session In View로 JPA에서는 Open EntityManager In View가 맞지만 관례상 OSIV라고 한다. OSIV ON spring.jpa.open-in-view: true # 기본값 OSIV 전략은 트랜잭션 시작처럼 최초 데이터베이스 커넥션 시작 시점(Service 계층)부터 API 응답이 끝날 때(Controller 계층)까지(유저에게 응답이 갈 때까지) 영속성 컨텍스트와 데이터베이스 커넥션을 유지한다. 그래서 View Template이나 지연 로딩이 가능하다. 지연 로딩은 영속성 컨텍스트가 살아있어야 가능하고, 영속성 컨텍스트는 기본적으로 데이터베이스 커넥션을 유지한다. 이것은 큰 장점이다. 하지만, 이 전략은 너무 오랜 시간 동안 데이터베이스 커넥션 리소스.. [JPA] 컬렉션(일대다) 조회 최적화 JPA에서 일대다 관계일 때, fetch join을 사용하면 데이터가 뻥튀기된다. @Query("select o from Order o join fetch o.orderItems oi") JPA의 distinct를 사용하면 데이터 뻥튀기를 어느 정도 해결 가능하다. @Query("select distinct o from Order o join fetch o.orderItems oi") distinct를 사용하는 방법은 DB에서는 뻥튀기된 값을 가져와서, JPA가 Order의 id가 같은 것을 제거해 준다. 이러한 방법은 페이징이 불가능하다. DB에서 뻥튀기된 값을 모두 메모리에 올린 다음 메모리에서 정렬을 거쳐 페이징을 하게 된다. 가져오는 데이터가 많다면 Out of Memory가 발생할 수 있다. 또.. [JPA] N+1 문제 JPA를 사용하다 보면 의도하지 않은 쿼리문 여러 개가 나가는 현상을 볼 수 있다. 이러한 현상은 N+1 문제라고 부르며, 이번에는 N+1 문제에 대해 알아보자. N+1 문제 N+1 문제란, 연관 관계를 가지는 엔티티를 조회하는 쿼리(1개)에 의해 그와 연관 관계를 가지는 엔티티를 조회하는 쿼리(N개)가 추가로 발생하는 현상이다. 구성 @Entity @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) @AllArgsConstructor @Builder public class Member { @Id @GeneratedValue @Column(name = "member_id") private Long id; private String name; @Many.. @RequestMapping 사용자가 웹 페이지를 통해 요청을 하면, DispatcherServlet에서 요청에 맞는 컨트롤러를 찾아 호출해준다고 배웠다. 스프링에서는 @RequestMapping 어노테이션을 지원하여 어떤 요청에 대해 어떤 컨트롤러가 호출되어야 하는지 알려준다. 그럼 어떤식으로 동작하는지 코드와 함께 알아보자. @Controller public class RequestMappingController { @RequestMapping("/hello") public String hello(Model model){ model.addAttribute("name", "꽁탁"); return "hello"; } } 위의 코드에서 @RequestMapping를 통해 /hello라는 URL 요청에 들어오면 hello라는 뷰의 논리.. Spring MVC 먼저 MVC 패턴에 대해 알아보자. MVC 패턴 MVC는 Model, View, Controller의 약자로 하나의 애플리케이션의 구성 요소를 세 가지의 역할로 구분한 개발 방법론이다. [MVC 패턴] Model Model은 애플리케이션의 정보, 데이터를 나타낸다. Model은 DB의 역할과 같이 사용자가 필요한 데이터를 가지고 있다. 비즈니스 로직을 처리한 후 Model의 변경사항을 Controller와 View에 전달한다. View View는 사용자에게 무엇을 보여주기 위한 역할을 수행한다. Model에게 전달 받은 데이터를 화면에 표시해준다. Controller Controller는 사용자의 요구사항을 파악한 후에 그 요청에 맞는 데이터를 Model에 요구하고 데이터를 View에 반영한다. MVC .. 스프링 빈 생명주기 콜백 데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션의 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다. 이번에는 스프링을 통해 이러한 초기화 작업과 종료 작업을 어떻게 진행하는지 알아보자. 스프링 빈은 다음과 같은 생명주기를 가진다. 빈의 생명주기 스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 컨테이너 종료 스프링은 3가지 방법으로 빈 생명주기 콜백을 지원한다. 1. 인터페이스 InitializingBean, DisposableBean 첫 번째는 InitializingBean 인터페이스와 DisposalBean 인터페이스를 상속.. 스프링 컨테이너, 스프링 빈, 싱글톤 스프링은 SOLID 원칙을 준수하기 위해 IoC, DI 등을 지원하고 있다. 이를 위해 스프링 컨테이너가 존재한다. 위의 목적을 달성하기 위해 자바 객체를 스프링 컨테이너에서 직접 관리한다. 관리하는 자바 객체를 빈이라고 하고 이름과 객체를 한 묶음으로 관리하게 된다. 그림으로 표현하면 다음과 같다. [스프링 컨테이너] 실제로 스프링이 어떻게 객체를 주입하는지 코드를 통해 알아보자. @Configuration public class AppConfig { @Bean public MemberService memberService(){ return new MemberServiceImpl(memberRepository()); } @Bean public MemberRepository memberRepository.. 이전 1 2 다음
