0124 - 0206

0125 - JPA 사용시 엔티티 상태 확인하기

JPA를 사용할 때 반드시 알아야 하는 것중 하나가 엔티티 객체의 상태 변화인데 JPA를 쓰면서 Transient(New), Persistent, Detached, Deleted 이런 상태 변화와 그 특징에 대한 공부를 한적이 없다면 JPA를 잘못쓰고 있을 가능성이 크다.

이 중에서도 Persistent 상태가 가장 중요한데, 하이버네이트가 한 트랜잭션 내에서 불필요한 쿼리를 줄요주는 역할을 하기 때문이다. 흔히 1차 캐시라고 부르는 Persistent Context가 해당 인스턴스를 이미 담고 있기 때문에 DB에서 쿼리를 하더라도 불필요한 select 쿼리가 발생하지 않는다.

private void savePost() {
    Post post = new Post();
    post.setTitle("keesun");
    
    Post newPost = postRepository.save(post);
    System.out.println(postRepository.findById(newPost.getId()));
}

새 글을 저장하고 findById를 통해 id로로 저장했던 Post를 다시 가져오는 코드이다. 이 때 postRepository가 스프링 데이터 JPA를 사용하지 않고 스프링 JDBC를 사용해 구현하거나 스프링 데이터 JDBC를 사용해 구현했다면 이 코드는 분명히 insert 쿼리 이후에 select 쿼리가 발생한다.

하지만, postRepository를 스프링 데이터 JPA가 제공하는 JpaRepository 인터페이스를 상속받아 구현했다면, 이 코드는 insert 쿼리만 발생하고 select 쿼리는 발생하지 않는게 이론적으로 맞다. save()를 호출 했을 떄 newPost(post와 같은 인스턴스)가 Persistent 상태로 영속화 컨텍스트인 EntityManager(또는 하이버네이트의 Session)에 캐시에 캐시가 되기 떄문이다. 그래서 해당 id를 가지고 있는 Post 인스턴스를 DB에서 꺼내오는게 아니라 캐시하고 있는 메모리에서 꺼내주고, 따라서 select 쿼리는 발생하지 않는게 맞다.

그리고 실제 해당 객체가 Persistent 상태인지 확인하려면 EntityManager를 주입 받아서 contains 메소드를 통해 확인할 수 있다.

entityManager.contains(post);

• 확인

@Component
public class JpaRunner implements ApplicationRunner {

    @PersistenceContext
    EntityManager entityManager;

    @Autowired
    PostRepository postRepository;

    @Override
    public void run(ApplicationArguments args) throws Exception {
        savePost();
    }

    @Transactional
    private void savePost() {
        Post post = new Post();
        post.setTitle("keesun");

        Post newPost = postRepository.save(post);
        System.out.println(postRepository.findById(newPost.getId()));
        System.out.println(entityManager.contains(newPost));
    }
}

• 결과

2020-08-26 22:04:22.546  INFO 54359 --- [           main] m.w.demodomainclassconverter.App         : Started App in 2.062 seconds (JVM running for 2.458)
Hibernate: call next value for hibernate_sequence
Hibernate: insert into post (title, id) values (?, ?)
Hibernate: select post0_.id as id1_0_0_, post0_.title as title2_0_0_ from post post0_ where post0_.id=?
Optional[me.whiteship.demodomainclassconverter.Post@7ac48e10]
false

insert 쿼리 이후에 select 쿼리가 발생했고, EntityManager의 contains를 통해 Persistent 상태가 맞는지(EntityManager) 확인시 false가 출력됐다. 문제는 savePost 메소드에 트랜잭션이 적용되지 않아서 이다.

결론은 간단하지만 구체적으로 '왜 트랜잭션이 적용되지 않았지?'에 답하려면 스프링이 애노테이션 기반의 트랜잭션을 어떻게 처리하는지 이해해야 하는데 @Transaction이라는 애노테이션을 쓰는건 맞지만 private 메소드에 쓰는건 무의미하다. 오버라이딩이 가능한 메소드에 써야한다. 그렇다면 savePost() 메소드를 public으로 변경해보자.

@Transactional
public void savePost() {
    Post post = new Post();
    post.setTitle("keesun");

    Post newPost = postRepository.save(post);
    System.out.println(postRepository.findById(newPost.getId()));
    System.out.println(entityManager.contains(newPost));
}

public 메소드로 바꿨지만 이렇게 해도 savePost()에는 트랜잭션이 적용되지 않고 영속화 컨텍스트는 newPost를 캐싱하지 않는다. 그래서 결과는 private 메소드를 사용했을 때와 동일하다. 그 이유는 스프링의 트랜잭션 처리가 스프링 AOP를 기반으로 하고 있으며 스프링 AOP가 다이나믹 프록시를 기반으로 동작한다는 것을 알고 있다면 이렇게 해도 트랜잭션이 적용되지 않는 이유를 이해할 수 있을 것이다.

프록시 기반 AOP의 단점중에 하나인 프록시 내부에서 내부를 호출할 때는 부가적인 서비스(여기서는 그게 바로 트랜잭션)가 적용되지 않는다. 호출하려는 타겟을 감싸고 있는 프록시를 통해서만 부가적인 기능이 적용되는데 프록시 내부에서 내부를 호출 할 때는 감싸고 있는 영역을 거치지 않기 때문이다.

!(image)[https://www.whiteship.me/content/images/size/w1000/2020/08/Screen-Shot-2020-08-27-at-20.28.13.png]

프록시로 감싼 타겟(JpaRunner)를 외부에서 호출할 때 run()이라는 public 메소드를 호출하는데 (ApplicationRunner를 구현했기 때문에) 이 때 run() 메소드에는 트랜잭션이 적용되지 않는다. 왜냐면 @Transactional을 savePost()만 붙였기 때문이다. 그런데 그렇게 호출한 run()이 내부에서 @Transactional을 사용한 savePost()를 호출하더라도, JpaRunner 밖에서 호출이 되는게 아니라 프록시 내부에서 savePost()를 바로 호출하기 때문에 타겟을 감싼 트랜잭션이 적용되지 않는 것이다. 차라리 JpaRunner밖에서 savePost() 메소드를 바로 호출했다면 트랜잭션이 적용됐을 것이다.

해결하는 방식은 여러가지 방법이 있지만 제일 간단한 방법은 @Transactional을 run() 메소드로 옮기면 된다. 그럼 run()을 호출 할때부터 트랜잭션이 적용되면서 그 메소드에서 호출하는 다른 메소드도 전부 해당 트랜잭션 안에서 처리하기 때문에 insert 쿼리 이후에 select도 발생하지 않으며 EntityManager의 contains 메소드가 true를 릴턴하는 것을 확인할 수 있다.

@Transactional
@Override
public void run(ApplicationArguments args) throws Exception {
    savePost();
}

public void savePost() {
    Post post = new Post();
    post.setTitle("keesun");

    Post newPost = postRepository.save(post);
    System.out.println(postRepository.findById(newPost.getId()));
    System.out.println(entityManager.contains(newPost));
}

0202 - AllArgsConstructor, RequiredArgsConstructor의 staticName 옵션

staticName 옵션

staticName 옵션을 사용하여 생성자를 private로 생성하고, private 생성자를 감싸고 있는 static factory 메소드를 추가 할 수 있다.

@AllArgsConstructor(staticName = "of")
public class TestDTO {
    private int price;
    private int discount;
    private final int amount;
}

-----------------------------------------

@Getter
public class TestDTO {
    private int price;
    private int discount;
    private final int amount;

    private TestDTO(int amount){
        this.amount = amount;
    }


    public static TestDTO of(int i) {
       return new TestDTO(i);
    }
}

private 생성자가 생성되고, private 생성자를 감싸는 static factory 메소드 생성

class TestDTOTest {

    @Test
    public void test1(){
        TestDTO testDTO = TestDTO.of(4);
        assertNotNull(testDTO);
        assertEquals(0, testDTO.getPrice());
        assertEquals(0, testDTO.getDiscount());
        assertEquals(4, testDTO.getAmount());
        System.out.println("testDTO.getPrice() = " + testDTO.getPrice());
        System.out.println("testDTO.getDiscount() = " + testDTO.getDiscount());
        System.out.println("testDTO.getAmount() = " + testDTO.getAmount());

    }
}

정적 팩토리 메소드의 장단점

장점

• 이름이 있으므로 생성자에 비해 가독성이 좋다
• 호출할 때마다 새로운 객체를 생성할 필요가 없다
• 하위 자료형 객체를 반환할 수 있다
• 형인자 자료형(parameterized type) 객체를 만들 때 편하다

단점

• 정적 팩토리 메서드만 있는 클래스라면, 생성자가 없으므로 하위 클래스를 못 만든다
• 정적 팩토리 메서드는 다른 정적 메서드와 잘 구분되지 않는다

// 하위 자료형 객체를 반환
class OrderUtil {

    public static Discount createDiscountItem(String discountCode) throws Exception {
        if(!isValidCode(discountCode)) {
            throw new Exception("잘못된 할인 코드");
        }
        // 쿠폰 코드인가? 포인트 코드인가?
        if(isUsableCoupon(discountCode)) {
            return new Coupon(1000);
        } else if(isUsablePoint(discountCode)) {
            return new Point(500);
        }
        throw new Exception("이미 사용한 코드");
    }
}

class Coupon extends Discount { }
class Point extends Discount { }

할인 코드의 규칙에 따라 Coupon과 Point 객체를 선택적으로 리턴하고 있다.
이를 위해서는 두 하위 클래스가 같은 인터페이스를 구현하거나, 같은 부모 클래스를 갖도록 하면 된다.

만약 파일이 분리하기 애매한 작은 클래스가 있다면 private class를 활용할 수도 있다.

// java.util.Collections에서 EMPTY_MAP 부분
@SuppressWarnings("rawtypes")
public static final Map EMPTY_MAP = new EmptyMap<>();

/**
 * Returns an empty map (immutable).  This map is serializable.
 */
@SuppressWarnings("unchecked")
public static final <K,V> Map<K,V> emptyMap() {
    return (Map<K,V>) EMPTY_MAP;
}

private static class EmptyMap<K,V> extends AbstractMap<K,V> implements Serializable {
    /* 생략 */
}

EmptyMap 클래스는 java.util.Collections 내에 private static으로 선언되어 있으며, emptyMap이라는 정적 팩토리 메서드를 통해 캐스팅된 인스턴스를 얻을 수 있다.