전체 글
JPA Dirty Checking 시 update query 분석 (+ 모든 필드가 업데이트 되는 이유)
1. 알고자 하는 것 - JPA의 Dirty Checking 시 발생하는 update query를 확인한다. - 수정된 필드만 update query를 날리는 것이 아닌, 모든 필드에 대해 update query가 나가는 이유를 분석한다. 2. 알게된 것 JPA의 Dirty Checking 시 발생하는 update query를 확인 - JPA의 Dirty Checking(변경 감지)은 트랜잭션 내에서 Entity의 변경사항을 DB에 자동으로 반영해주는 기능이다. - 영속성 컨텍스트 내에서 최초 조회 시의 Entity에 대한 스냅샷을 보관하고 - 트랜잭션 커밋 시 EntityManager가 flush를 수행할 때, 스냅샷과 Entity를 비교한다. - 변경 내용에 대해 쓰기 지연 SQL 저장소에 updat..
Spring JdbcTemplate에서는 SQLException를 어떻게 처리했을까?
1. 알고자 하는 것 - 일반적으로 jdbc를 사용해 쿼리를 수행하면 다음과 같이 Checked Exception인 SQLException이 필연적으로 throws 된다. public void deleteAll() throws SQLException { Connection c = null; PreparedStatement ps = null; // getConnection, prepareStatement, executeUpdate 모두 SQLException을 throws 한다. c = dataSource.getConnection(); ps = c.prepareStatement("delete from users"); ps.executeUpdate(); // 자원 정리(close) 코드는 편의상 생략. } ..
외부 메서드, 내부 메서드에 대한 @Transactional 트랜잭션 적용 결과 테스트
1. 알고자 하는 것 - AOP 개념을 다시 한번 공부하며 프록시와 내부메서드 호출에 따른 트랜잭션 적용 결과를 테스트 해보고자 한다. - 다음과 같은 메서드(외부)와 해당 메서드 내에서 호출하는 메서드(내부)에 각각 @Transactional 어노테이션을 적용하였을 때 각 메서드에 대한 트랜잭션 적용 결과를 확인한다. 1. outerMethod (@Transactional) & innerMethod (@Transactional) 2. outerMethod (@Transactional) & innerMethod 3. outerMethod & innerMethod (@Transactional) @Slf4j @Service public class SimpleService { public void outerM..
Java 리팩토링 - 메서드 추출 시 매개변수가 많아질 경우 [2. 매개변수 객체 만들기]
1. 알고자 하는 것 - 메서드를 추출할 때(Extract method), 해당 메서드에 넘겨야 하는 매개변수가 많아질 경우의 리팩토링 1. 임시 변수를 질의 함수로 바꾸기 (Replace Temp with Query) 2. 매개변수 객체 만들기 (Introduce Parameter Object) 3. 객체 통째로 넘기기 (Preserve Whole Object) 2. 알게된 것 매개변수 객체 만들기 (Introduce Parameter Object) - 같은 매개변수 패턴이 여러 메서드에 걸쳐 나타난다면, 그 매개변수들을 묶은 자료구조를 만들 수 있다. - 이를 통해 해당 데이터간의 관계를 보다 명시적으로 나타낼 수 있다. (클래스명을 명시적으로 지정할 수 있으므로) - 함수에 전달할 매개변수 개수를 ..
Java 리팩토링 - 메서드 추출 시 매개변수가 많아질 경우 [1. 임시 변수를 질의 함수로 바꾸기]
1. 알고자 하는 것 - 메서드를 추출할 때(Extract method), 해당 메서드에 넘겨야 하는 매개변수가 많아질 경우의 리팩토링 1. 임시 변수를 질의 함수로 바꾸기 (Replace Temp with Query) 2. 매개변수 객체 만들기 (Introduce Parameter Object) 3. 객체 통째로 넘기기 (Preserve Whole Object) 2. 알게된 것 임시 변수를 질의 함수로 바꾸기 (Replace Temp with Query) - 긴 메서드를 메서드 추출을 통해 리팩토링 할 때, 임시 변수를 메서드로 추출하여 분리함으로써 매개변수의 개수를 줄인다. try (FileWriter fileWriter = new FileWriter("participants.md"); PrintWr..
Java 리팩토링 - 짧은 메서드 vs 긴 메서드 & Extract Method
1. 알고자 하는 것 - 짧은 메서드 vs 긴 메서드, 무엇이 더 좋은 코드인가? - 짧은 메서드를 만들기 위한 메서드 추출 (Extract method) 2. 알게된 것 짧은 메서드 vs 긴 메서드, 무엇이 더 좋은 코드인가? - (긴 메서드) 메서드가 길수록 코드의 가독성이 떨어진다. - (짧은 메서드) 짧고 많은 메서드로 구성되어 문맥 전환이 많아진다. - "과거에는" 과도한 서브루틴 호출로 오버헤드가 존재했다. - 현재는 서브루틴 호출으로 인한 오버헤드까지 고려하며 코드를 짤 필요는 없다. - 짧은 메서드에 대해 "좋은 이름 (= 가독성이 좋은 이름)"을 사용했다면 해당 메서드의 코드를 보지 않아도 의미를 이해할 수 있다. - 기억하자. '구현'을 나타내야 하는 것이 아니라, '의미'를 나타내는 ..
인터페이스의 default method와 다이아몬드 문제
1. 알고자 하는 것 - default method란 무엇인지 - 자바의 인터페이스에 default method가 고안된 이유는 무엇인지 - default method가 가능해짐에 따라 발생할 수 있는 다이아몬드 문제 (Diamond Problem)를 자바는 어떻게 해결하는지 2. 알게된 것 Default Method - 원래 자바에서 인터페이스(Interface)에는 오직 상수와 추상 메서드만을 가질 수 있었다. - 이로 인해 다음 사례와 같은 개발자들의 불편함이 생겼다. 1. A 인터페이스를 구현한 n개의 클래스가 있다. 2. 설계의 변경으로 A 인터페이스를 구현한 n개의 클래스에 대해 공통 메서드가 하나 추가되었다. 3. 이 때, A 인터페이스에 추상 메서드를 추가하고, n개의 클래스에 대해 추상 ..
참조변수와 인스턴스에 따른 method, 변수, static method 참조 결과 비교
1. 알고자 하는 것 - 자바는 객체지향언어로써 다형성을 적용할 수 있다. - 다형성 : 한 타입의 참조변수로 여러 타입(상속, 구현관계)의 객체를 참조할 수 있도록 하는 것 - Parent와 Child 클래스 관계에서 참조변수와 해당 변수에 할당된 인스턴스의 타입에 따라 호출하는 method, 변수, static method의 참조 결과는 어떻게 되는가? 2. 알게된 것 class Parent { String name = "Parent"; public void method() { System.out.println("Parent Method"); } public void methodOverriding() { System.out.println("Parent methodOverriding()"); } pub..
No-Offset 적용을 통한 무한 스크롤 방식의 페이징 쿼리 성능 개선
프로젝트 리팩토링을 진행하며, 무한 스크롤 방식의 페이징이 적용되어 있는 기능에 대해 효율적인 성능 개선 방식을 학습하게 되어 신나게 기록하게 되었따. 페이징 기능은 대량의 데이터를 한꺼번에 조회할 때, 성능의 저하가 발생하므로 일정량의 개수로 데이터를 page 단위로 나누어 조회하는 방식으로, 목록 조회 시 필수적으로 구현되는 기능 중 하나이다. 이러한 페이징은 보통 다음과 같이 limit과 offset을 사용한 일반적인 방식으로 구현된 다. SELECT * FROM member ORDER BY id DESC OFFSET pageNum * pageSize LIMIT pageSize 하지만 이러한 페이징 방식은 데이터가 많아질수록 과거의 값을 조회할 때 다음과 같은 이유로 인해 성능이 저하된다. - 매번..
@Transactional(readOnly = true)를 왜 붙여야 하나요
스프링으로 개발하면서 필연적으로 사용하게 되는 @Transactional. 우리는 스프링의 AOP를 통해 @Transactional 어노테이션만으로 손쉽게 Service Layer에서 트랜잭션을 걸 수 있다. 일반적으로, 조회용 메서드에 대해서는 @Transactional(readOnly = true) 를 설정함으로써 성능상 이점을 얻을 수 있다고 한다. 그렇구나,, 하고 넘어갈 수도 있지만 딱 한 깊이만 더 들어가서 학습한다면 더 다채로운 지식을 얻을 수 있지 않을까? 더도말고 딱 한 번만 더 깊이 들어가보자. 왜? 라는 물음을 통해 readOnly = true 시에 어떠한 성능상 이점 + 추가적인 장점이 있는지 알아보며 지식을 한층 더 넓혀보자 :) 그래서, 왜? (1) - JPA 관련 그래서 왜 r..