🗄️

프록시 객체가 실제 값을 가지는 시점

생성일

2022/08/18

태그

Spring

JPA

배경

저희 모락 프로젝트의 서비스 로직 개발 중, equals 로 비교해야 할 로직이 필요했습니다. 조금 더 구체적으로는 투표를 생성한 호스트와, 수정/삭제를 요청한 멤버가 같은지 확인하는 로직이었습니다. 그래서 findById 로 객체를 불러서 비교를 하려고 하는데 원하는대로 결과가 나오지 않고 계속 일치하지 않는다는 응답을 받았습니다. 그래서 equals 내부에 디버그를 찍어보니 이상하게 계속 인자로 받은 객체가 프록시 객체로 저장되어 있었습니다.

JPA 는 프록시 객체를 영속성 컨텍스트에 저장하고 이를 다양한 부분에서 활용합니다. 이 덕분에 DB 커넥션을 할 때 발생하는 성능 저하를 줄이고, 이 기능이 JPA 의 가장 강력한 기능 중 하나입니다. 하지만 조회 시 영속성 컨텍스트에 조회를 원하는 객체가 없으면 반드시 DB 를 찔러 해당 객체를 가지고 와야 하고, 저희가 만든 로직에서는 해당 객체가 영속성 컨텍스트에 없다고 판단하였습니다. 이와 더불어 해당 객체를 조회하는 SQL 구문이 로그에 찍혔음에도 불구하고 계속 프록시 객체로 남아있었고, 이 과정에서 equals 내부 객체 비교 로직에서 false 로 반환되는 것이었습니다.

도대체 문제가 뭔지, 디버그를 찍어도 해결이 안되었고 코치분들께 도움을 요청하여 다행히 해당 문제를 해결할 수 있었습니다. 이 과정에서 알게된 내용과 해결 방법에 대해 공유하고자 합니다.

기본 세팅

저희는 투표와 멤버 도메인 사이에서 발생한 문제였는데, 해당 문제는 1:N 연관관계에서 발생하는 문제이기 때문에 조금 더 보편적인 예시를 들고자 합니다. 투표를 멤버로 바꾸고, 멤버를 팀으로 바꾸어 테스트를 진행하려고 합니다. 즉 멤버:투표=1:N 의 관계를 팀:멤버=1:N 으로 바꾼 예시입니다.

@Entity
@NoArgsConstructor
@Getter
public class Team {

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

    private String name;

    @Override
    public boolean equals(Object o) {
        if (this == o)
            return true;
        if (o == null || getClass() != o.getClass())
            return false;
        Team team = (Team)o;
        return Objects.equals(getId(), team.getId()) && Objects.equals(getName(), team.getName());
    }

    @Override
    public int hashCode() {
        return Objects.hash(id, name);
    }
}
Java
복사

비교를 위해 equals 를 재정의하였습니다.

@Entity
@NoArgsConstructor
@Getter
public class Member {

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

    private String name;

    @ManyToOne(fetch = FetchType.LAZY)
    private Team team;

    public boolean isTeam(Team team) {
        return this.team.equals(team);
    }
}
Java
복사

저희가 발생했던 환경과 동일하게 하기 위해 1:N @ManyToOne 연관 관계를 설정하였습니다.

@Service
@RequiredArgsConstructor
public class MorakService {

    private final MemberRepository memberRepository;
    private final TeamRepository teamRepository;

    public boolean test(Long memberId, Long teamId) {
        Member member = memberRepository.findById(teamId).orElseThrow();
        Team team = teamRepository.findById(memberId).orElseThrow();

        return member.isTeam(team);
    }
}
Java
복사

member 와 team 을 조회하고 비교 로직을 수행하였습니다.

문제 지점 확인

문제 지점 확인을 위해 테스트를 돌렸습니다. 더미 데이터는 다음과 같이 넣었습니다.

Team

id	name
1	morak

Member

id	name	team_id
1	eden	1

@Test
@DisplayName("같은 팀인지 확인한다.")
void test() {
		//given
    Long memberId = 1L;
    Long teamId = 1L;

		//when
		boolean isSameTeam = morakService.test(memberId, teamId);

		//then
    assertThat(isSameTeam).isTrue();
}
Java
복사

테스트를 돌리면 조회한 팀(id=1)과 멤버에 저장된 팀(id=1)이 같은데 실패합니다.

과정

차근차근 서비스 로직부터 디버그를 돌려 보았습니다.

조회 이후 찍은 디버그에서 member 의 team 과 team 둘 다 프록시 객체로 설정되어 있었습니다. member 의 team 은 member 조회 시 fetch type 을 lazy 로 해서 이해가 되었지만, team 조회 시에도 team 이 프록시 객체로 있는 것이 이상했습니다. 이 현상은 일단 나중에 확인한다 해도, 멤버의 팀과 조회한 팀은 둘 다 프록시 객체이고 같은 주소값을 가지는데 왜 false 가 나타났는지 이해가 되지 않았습니다.

내부 로직으로 디버그를 더 들어가 보았습니다.

•

member.isTeam(team) 내부

현재까지도 member 의 team 과 파라미터로 들어온 team 모두 같은 주소값을 가지는 동일한 프록시 객체입니다.

•

Override 한 team.equals(team) 내부

this 인 ‘member 의 team’ 이 Team 객체로 바뀌었습니다. 하지만 파라미터로 들어온 team(변수명 o)은 여전히 프록시 객체였고, getClass() != o.getClass() 에서 false 로 걸러진 것이었습니다.

어떻게 메서드 호출이 프록시를 실제 데이터 객체로 만들게 되는 것일까?

프록시 객체의 메서드가 호출되면 ProxyConfiguration 내부의 InterceptorDispatcher 클래스의 intercept 메서드가 먼저 실행됩니다.

public interface ProxyConfiguration {

		// ...
		
		interface Interceptor {

        @RuntimeType
        Object intercept(@This Object instance, @Origin Method method, @AllArguments Object[] arguments) throws Throwable;    
}

   class InterceptorDispatcher {

      @RuntimeType
      public static Object intercept(
            @This final Object instance,
            @Origin final Method method,
            @AllArguments final Object[] arguments,
            @StubValue final Object stubValue,
            @FieldValue(INTERCEPTOR_FIELD_NAME) Interceptor interceptor
      ) throws Throwable {
         if ( interceptor == null ) { // 1
            if ( method.getName().equals( "getHibernateLazyInitializer" ) ) {
               return instance;
            }
            else {
               return stubValue;
            }
         }
         else {
            return interceptor.intercept( instance, method, arguments );// 2
         }
      }
   }
}
Java
복사

1 에서 interceptor 가 null 이 아니기때문에 2가 실행됩니다. 해당 interceptor는 ProxyConfiguration.Interceptor 인터페이스에서 선언된 intercept(instance, method, arguments) 메서드를 호출됩니다. 해당 interceptor 인터페이스를 구현한 클래스는 아래의 ByteBuddyInterceptor 입니다.

public class ByteBuddyInterceptor extends BasicLazyInitializer implements ProxyConfiguration.Interceptor {

// ...

		public Object intercept(Object proxy, Method thisMethod, Object[] args) throws Throwable {
        Object result = this.invoke( thisMethod, args, proxy );
        if ( result == INVOKE_IMPLEMENTATION ) {
            Object target = getImplementation();
            final Object returnValue;
            try {
                if ( ReflectHelper.isPublic( persistentClass, thisMethod ) ) {
                    if ( !thisMethod.getDeclaringClass().isInstance(target) )  {
												// ...
                    }
                    returnValue = thisMethod.invoke( target, args );// - 2
                }
								// ...
								return returnValue;
            }
            catch (InvocationTargetException ite) {
                throw ite.getTargetException();
            }
        }
        else {
            return result;
        }
    }

    protected final Object invoke(Method method, Object[] args, Object proxy) throws Throwable {
        String methodName = method.getName();
        int params = args.length;

        if (params == 0) {
						// ...
        } else if (params == 1) {
            if (!overridesEquals && "equals".equals(methodName)) {// - 1
								return args[0] == proxy;
            } else if (method.equals(setIdentifierMethod)) {
                initialize();
                setIdentifier((Serializable) args[0]);
                return INVOKE_IMPLEMENTATION;
            }
        }
    }
}
Java
복사

interceptor() 가 호출되면 먼저 invoke() 메서드로 equals 를 오버라이드 했는지 확인합니다. 저희는 equals 를 오버라이드 했기때문에 1번의 !overridesEquals() 에서 false 가 되고 INVOKE_IMPLEMENTATION 을 리턴합니다. 이후 getImplementation() 으로 영속성 컨텍스트에서 실제 데이터를 가진 객체를 가져오고, 앞서 호출한 메서드(equals)가 2번의 thisMethod.invoke( target, args ); 로 실행됩니다.

해결 방법

1. fetch type EAGER

지연 로딩을 하지 않고 바로 불러오기때문에 이후에 불러오는 team 도 프록시 객체가 아닌 실제 객체가 됩니다.

하지만 팀 내부 회의 결과, 굳이 매번 EAGER 로 불러올 필요성을 느끼지 못하여 다른 방안을 생각하였습니다.

2. find 하는 순서를 바꾼다.

Team team = teamRepository.findById(memberId).orElseThrow();
Member member = memberRepository.findById(teamId).orElseThrow();
Plain Text
복사

team 을 먼저 불러 해당 team 이 바로 실제 객체가 되도록 합니다.

하지만 근본적인 해결책이 아니기때문에 매번 순서를 고려해야 합니다. 그래서 다른 방법을 또 찾아보았습니다.

3. equals 를 override 하지 않기

ByteBuddyInterceptor 의 invoke() 메서드에서 !overrideEquals 가 true 가 되어 두 객체 모두 프록시 객체로 남아 프록시 객체끼리의 비교가 가능합니다.

아무리 JPA 가 영속성 컨텍스트를 통해 동일성을 보장할 수 있다지만 제어권이 JPA 에 넘어가는 것 같았습니다.

4. equals override 커스텀하기

override 한 equals 에서 getClass() != o.getClass() 부분을 지워주고 !(o instanceof Team) 을 넣었습니다. 프록시 객체는 상속을 이용하여 생성되기 때문에 instanceof 키워드로 충분히 만족할 수 있습니다.

public boolean equals(Object o) {
    if (this == o) {
        return true;
    }
    if (o == null !(o instanceof Team)) {
        return false;
    }
    Team team = (Team) o;
    return Objects.equals(id, team.getId()) && Objects.equals(name, team.getName());
}
Kotlin
복사