N:1의 지연로딩, 외래키는 어디서 관리할까?(feat.AbstractLazyInitializer)

공병주(Chris)·2022년 8월 30일

N:1 관계에서 연관관계의 주인은 N입니다. 1의 PK를 N이 가지고 있습니다. 따라서, N을 조회할 때 1의 PK, 즉 외래키가 같이 조회됩니다. 이해를 위해 Member(N) : Team(1)의 관계로 설명을 해보겠습니다.

Member에서 Team을 Lazy Loading 하는 상황이라고 가정합시다. Team의 PK를 조회해도 Team에 대한 select문은 실행되지 않습니다. Member를 조회할 때, team_id를 함께 조회해오기 때문입니다.

그렇다면, team_id는 어디서, 어떻게 관리되고 있을까요?

@Entity
@Getter
public class Team {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "team_id")
    private Long id;

    @OneToMany(mappedBy = "team", fetch = FetchType.LAZY)
    List<Member> members = new ArrayList<>();

    @Column(name = "team_name")
    public String name;

    public Team(String name) {
        this.name = name;
    }

    protected Team() {
    }
}

@Entity
@Getter
public class Member {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Embedded
    private Username username;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "team_id")
    private Team team;

    public Member(String username, Team team) {
        this.username = new Username(username);
        this.team = team;
    }

    protected Member() {
    }
}

추측

저는 두 가지 중에 하나라고 추측했습니다.

Team의 Proxy 객체에 할당되어 있음
Proxy와 함께 Target 객체가 바로 생성되어서 Target 객체에 할당되어 있음. 그리고 이후에 해당 Team을 select 하고 추가적인 Team의 속성들을 Target 객체에 할당해줌

결과는 둘 다 아니었습니다…

그럼 찾아보자

먼저 Test를 위한 data를 준비했습니다.

insert into team (team_name) values ('A');
insert into team (team_name) values ('B');
insert into team (team_name) values ('C');
insert into team (team_name) values ('D');
insert into team (team_name) values ('E');
insert into member (name, team_id) values ('chris', 5);

member는 team_id가 5인 Team과 관계를 맺고 있습니다.

그 후, 아래와 같은 Test를 작성하고 sout이 작성된 line에 Breakpoint를 찍고, Member를 열어보았습니다.

@DataJpaTest
@Sql("classpath:test.sql")
class MemberRepositoryTest {

    @Autowired
    private MemberRepository memberRepository;

    @Test
    void myTest() {
        Member member = memberRepository.findById(1L)
                .orElseThrow(IllegalArgumentException::new);

        System.out.println("check it");
    }
}

일단 team에는 Proxy 객체가 할당되어 있는 것을 확인할 수 있습니다.

위의 team Proxy를 열어보면 null이 할당되어 있습니다. 저의 추측 1은 틀렸습니다.

그 후, $_hibernate_interceptor가 의심스러워서 열어보았습니다.

맨 아래에 id = {Long@9395}5를 확인할 수 있습니다. ByteBuddyInterceptor라는 객체에서 관리되고 있었습니다.

다른 값인데 우연히 5와 일치하는거 아닌가라는 생각이 들었습니다. 따라서, member의 team_id를 다른 값으로 변경하고 확인해보았는데, 변경한 team_id 값이 ByteBuddyInterceptor의 id 필드에 할당된 것을 확인했습니다.

ByteBuddyInterceptor에서 관리

N:1, N(Member)은 1(Team)을 Lazy Loading 하는 관계에서 N이 가지고 있는 1의 pk는 hibernate의 ByteBuddyInterceptor 객체에서 관리 됩니다.

조금 더 구체적으로 이야기하자면, ByteBuddyInterceptor는 아래와 같은 상속구조를 가집니다.

ByteBuddyInterceptor는 BasicLazyInitializer를 상속하고, BasicLazyInitializer는 AbstractLazyIntializer를 상속합니다. 위에서 본 id는 AbstractLazyIntializer에 존재합니다. 그리고 이를 상속하여 ByteBuddyInterceptor에서 사용하는 것입니다.

이들은 다 hibernate의 객체들입니다.

Team proxy와 Team의 id를 조회할 때, 해당 id가 사용되는지 확인하기

@Test
void myTest() {
    Member member = memberRepository.findById(1L)
            .orElseThrow(IllegalArgumentException::new);

    Team team = member.getTeam();
}

AbstractLazyIntializer.class

위와 같은 team을 조회하는 테스트를 작성하고, 아래의 AbstractLazyIntializer의 getInternalIdentifier에 breakpoint를 찍어보면 해당 메서드가 호출됨을 확인할 수 있습니다.

@Test
void myTest() {
    Member member = memberRepository.findById(1L)
            .orElseThrow(IllegalArgumentException::new);

     Long teamId = member.getTeam()
            .getId();
}