전뇌 페이지

[Fixture Monkey] giveMeBuilder().set()의 값이 적용되지 않음

the0 — Mon, 20 Oct 2025 12:31:32 +0900

1. 문제 상황

Fixture Monkey 1.1.11 버전 사용

Google Guava 라이브러리의 Range.class는 giveMeBuilder().set()으로 value가 적용되지 않음

(String, int, enum 등 자바 기본 자료형은 문제 없음)

@Test
void test_set_range() {
    Range<Instant> targetRange = Range.closed(
            Instant.parse("2025-01-01T00:00:00.000001Z"),
            Instant.parse("2025-12-31T23:59:59.999999Z")
    );

    var foo = fixture.giveMeBuilder(Foo.class)
            .setNull("id")
            .set("period", targetRange) // ⭐️ 이 부분
            .sample();

    assertThat(foo.getPeriod()).isEqualTo(targetRange);
}

테스트 결과:

org.opentest4j.AssertionFailedError: 
expected: [2025-01-01T00:00:00.000001Z..2025-12-31T23:59:59.999999Z]
 but was: [2025-05-18T00:59:34.612115Z..2025-11-23T00:59:34.612115Z]

이외 추가 참고 자료... ⬇️

Fixture Monkey는 Range 타입 객체 생성을 지원하지 않는다.

이에 따라 CustomArbitraryIntrospector를 활용해 Range 객체를 생성할 수 있는 RangeInstantArbitraryIntrospector도 만들어 두었다.

/**
 * Range<Instant> 타입에 대한 값을 반환하는 사용자 정의 인트로스펙터 예제
 */
public class RangeInstantArbitraryIntrospector implements ArbitraryIntrospector{
    @Override
    public ArbitraryIntrospectorResult introspect(ArbitraryGeneratorContext context){
        Property property = context.getResolvedProperty();
        Class<?> type = Types.getActualType(property.getType());
        List<AnnotatedType> typeArguments = Types.getGenericsTypes(property.getAnnotatedType());
        Class<?> genericType = typeArguments.isEmpty() ? null : Types.getActualType(typeArguments.getFirst());

        if (!type.equals(Range.class)
                || typeArguments.size() != 1
                || !genericType.equals(Instant.class)) {
            return ArbitraryIntrospectorResult.NOT_INTROSPECTED;
        }
        
        Instant startTime = // 난수 생성 로직 생략
        Instant endTime = // 난수 생성 로직 생략

        Range<Instant> rangeValue = Range.closed(startTime, endTime);
		
        return new ArbitraryIntrospectorResult(
                CombinableArbitrary.from(rangeValue)
        );
    }
}

FixtureMonkey fixtureMonkey = FixtureMonkey.builder()
        .pushArbitraryIntrospector(
                new MatcherOperator<>(
                        new AssignableTypeMatcher(Range.class).intersect(new SingleGenericTypeMatcher()),
                        rangeInstantArbitraryIntrospector
                )
        )
        .build();

2. 해결 방법

Values.just()를 사용한다.

@Test
void test_set_range() {
    Range<Instant> targetRange = Range.closed(
            Instant.parse("2025-01-01T00:00:00.000001Z"),
            Instant.parse("2025-12-31T23:59:59.999999Z")
    );

    var foo = fixture.giveMeBuilder(Foo.class)
            .setNull("id")
            .set("period", Values.just(targetRange)) // ⭐️ 이 부분
            .sample();

    assertThat(foo.getPeriod()).isEqualTo(targetRange);
}

2.1. 추가 설명

2.1.1 Values.just()

Fixture Monkey는 기본적으로 set()을 사용할 때,

원본 값을 그대로 사용하지 않고 내부적으로 값을 분해해서 재구성하는 깊은 복사를 수행한다.

만약 이미 만들어진 객체를 내부 작업(분해-재구성) 없이 직접 할당하고 싶으면 Values.just()를 사용하면 된다.

2.1.2. Range 타입 값이 set 되지 않았던 원인

Fixture Monkey는 Range.class를 깊은 복사하지 못하기 때문이다.

value를 set하기에 앞서, Fixture Monkey는 Range 클래스 자체를 분석한다.

NodeSetDecomposedValueManipulator.java 참고

isContainer() = false → 일반 객체로 인식

-> children.isEmpty() = false && isInterface() = false

-> 루트 객체에 대해서는 setArbitrary() 호출을 하지 않고 자식 필드 값을 처리한다.

arbitrary 필드란
이 값이 설정된 경우 사용자가 원하는 값(.set())을,
설정되지 않으면 ArbitraryIntrospector가 자동 생성하는 값을 사용하도록 지시하는 필드이다.

.set()을 했음에도 불구하고,

Fixture Monkey는 Range.closed() 분배 후 재조립이 되지 않고,

이는 추후에 arbitrary = null

-> 커스텀 인트로스펙터인 RangeInstantArbitraryIntrospector 호출

-> RangeInstantArbitraryIntrospector 내부에서 생성된 랜덤 값이 적용

되는 과정을 거친다.

※ Values.just() 인 경우, Range.class 클래스 분석 없이 setArbitrary(CombinableArbitrary.from(exactValue)) 를 한다.

[Fixture Monkey] CustomArbitraryIntrospector를 등록하는 여러 방법

the0 — Sun, 19 Oct 2025 22:21:37 +0900

[Fixture Monkey] 불변 객체를 위한 사용자 정의 인트로스펙터 예제 코드 - 기초편

불변 객체(`google.common.collect.Range`)를 위한 사용자 정의 인트로스펙터 예제 코드입니다.사용 버전: 1.1.11 ⬇️ 코드만 먼저 보기더보기더보기더보기/** * Range 타입에 대한 값을 반환하는 사용자 정

the0.tistory.com

이전 포스팅 글(사용자 정의 인트로스펙터 예제 코드 - 기초편)과 이어집니다.

공식문서를 참고하여 Fixture Monkey의 CustomArbitrayIntrospector를 만들고

customIntrospector를 objectIntrospector에 등록했다.

참고: https://naver.github.io/fixture-monkey/v1-1-0-kor/docs/generating-objects/custom-introspector/#다른-인트로스펙터와-함께-사용

FixtureMonkey fixtureMonkey = FixtureMonkey.builder()
    .objectIntrospector(new FailoverIntrospector(
        Arrays.asList(
            rangeInstantArbitraryIntrospector,  // ⭐️ 사용자 정의 인트로스펙터
            ConstructorPropertiesArbitraryIntrospector.INSTANCE,
            BuilderArbitraryIntrospector.INSTANCE,
            FieldReflectionArbitraryIntrospector.INSTANCE,
            BeanArbitraryIntrospector.INSTANCE
        )
    ))
    .build();

이후 `giveMeOne()` 혹은 `giveMeBuilder().sample()` 등 수행 과정을 디버깅해본 결과,

모든 Request/Response 객체가 생성될 때마다 rangeInstantArbitraryIntrospector에 접근한다.

public class RangeInstantArbitraryIntrospector implements ArbitraryIntrospector {

    @Override
    public ArbitraryIntrospectorResult introspect(ArbitraryGeneratorContext context) {

        Property property = context.getResolvedProperty();
        Class<?> type = Types.getActualType(property.getType());
        List<AnnotatedType> typeArguments = Types.getGenericsTypes(property.getAnnotatedType());
        Class<?> genericType = typeArguments.isEmpty() ? null : Types.getActualType(typeArguments.getFirst());

        if (!type.equals(Range.class)
                || typeArguments.size() != 1
                || !genericType.equals(Instant.class)) {
            return ArbitraryIntrospectorResult.NOT_INTROSPECTED;
        }

        // 후략
    }
}

이 RangeInstantArbitraryIntrospector는 Range.class 이면서 제네릭이 Instant인 타입을 위한 Custom Introspector이다.

하지만 Foo.class 를 비롯한 사용자 정의 객체들이 모두 접근하고, if 조건문에서 return 된다.

Foo.class는 예시 클래스입니다. ⬇️

import java.time.Instant;
import com.google.common.collect.Range;

public record Foo(
	...
	Range<Instant> period,
 	...
) {
}

// 예시: ["2025-10-06 01:00:00.000+00","2025-10-06 09:00:00.000+00"]

커스텀 Introspector를 특정 Class에만 적용하는 방법이 있을까?

당연히 존재한다.

이 아티클에서는 인트로스펙터를 설정하는 방법을 다룬다.

참고 자료:

- https://naver.github.io/fixture-monkey/v1-0-0-kor/docs/fixture-monkey-options/generation-options/#arbitraryintrospector

0. Fixture Monkey 인트로스펙터 적용/검증 순서

JavaArbitraryIntrospector : String.class, char.class, int.class, Long.class 등

→ JavaTimeArbitraryIntrospector : Date.class, LocalDateTime.class, Instant.class, ZoneId.class 등

→ priorityIntrospector : Boolean.class, boolean.class UUID.class, Enum 타입
→ containerIntrospector : Optional.class, Set.class, Queue.class, Stream.class, Map.class 등

→ objectIntrospector : JavaBean 패턴을 따르는 객체들을 분석, 생성

→ fallbackIntrospector : 아무 인트로스펙터들도 처리하지 못했다는 결과 반환

이 아티클에서 일련의 모든 내장 Introspector를 JavaDefaultArbitrary라고 칭하겠다.

참고 ⬇️

Fixture Monkey 소스코드

/*
JavaDefaultArbitraryGeneratorBuilder.java
line 168 ~ 181
*/

public IntrospectedArbitraryGenerator build() {
	return new IntrospectedArbitraryGenerator(
		new MatchArbitraryIntrospector(
			Arrays.asList(
				new JavaArbitraryIntrospector(this.javaTypeArbitraryGeneratorSet),
				new JavaTimeArbitraryIntrospector(this.javaTimeArbitraryGeneratorSet),
				this.priorityIntrospector,
				this.containerIntrospector,
				this.objectIntrospector,
				this.fallbackIntrospector
			)
		)
	);
}

1. 기존 방식 : objectIntrospector

인트로스펙터를 설정한 기존 방식은 다음과 같이 objectIntrospector에 등록했다.

FixtureMonkey fixtureMonkey = FixtureMonkey.builder()
    .objectIntrospector(new FailoverIntrospector(
        Arrays.asList(
            rangeInstantArbitraryIntrospector,  // ⭐️ 사용자 정의 인트로스펙터
            ConstructorPropertiesArbitraryIntrospector.INSTANCE,
            BuilderArbitraryIntrospector.INSTANCE,
            FieldReflectionArbitraryIntrospector.INSTANCE,
            BeanArbitraryIntrospector.INSTANCE
        )
    ))
    .build();

1.1. objectIntrospector 정의

ObjectIntrospector는 JavaBean 패턴을 따르는 객체들을 분석하고 생성한다.

프로젝트 내에서 작성한 DTO, DAO 등 클래스 객체들이 ObjectIntrospector의 주 대상이다.

1.2. 문제, 원인과 결론

문제 : 모든 Request/Response 객체가 생성될 때마다 rangeInstantArbitraryIntrospector에 접근한다.

원인: JavaBean 객체 하나하나가 FailoverIntrospector(Arrays.asList()) 에 등록되어 있는 순서대로 인트로스펙터에 접근해보기 때문

결론: 내가 원하는 Range.class인 경우에만 접근하고, 나머지 경우는 접근조차 하지 않도록 objectIntrospector가 아닌 ArbitraryIntrospector를 설정한다.

2. 개선 방식 : ArbitraryIntrospector 정의

ArbitraryIntrospector 는 Arbitrary를 생성하는 방법을 결정한다.

Arbitrary 생성 전략을 기반으로 Arbitrary가 만들어지고, 이를 기반으로 ObjectIntropsector를 활용해 객체가 생성된다.

아래 옵션을 사용하여 특정 타입에 대해 사용자 정의 ArbitraryIntrospector를 사용할 수 있다.

2.1. ArbitraryIntrospector 종류

- pushExactTypeArbitraryIntrospector

- pushAssignableTypeArbitraryIntrospector

- pushArbitraryIntrospector

2.1.2. pushExactTypeArbitraryIntrospector

지정된 클래스와 정확히 일치하는 타입에만 적용한다.

상속 관계는 무시된다.

public class Animal {}

// Dog 클래스 (Animal을 상속)
public class Dog extends Animal {}

// Animal 타입에만 적용, Dog는 적용 안됨.
FixtureMonkey fixtureMonkey = FixtureMonkey.builder()
    .pushExactTypeArbitraryIntrospector(Animal.class, customIntrospector)
    .build();

2.1.2. pushAssignableTypeArbitraryIntrospector

지정된 클래스의 하위 타입들에도 적용한다.

내부적으로 특정 Class가 어떤 클래스/인터페이스를 상속/구현했는지 체크하는 isAssignableFrom()을 사용하므로 상속 관계를 포함한다.

public class Animal {}

// Dog 클래스 (Animal을 상속)
public class Dog extends Animal {}

// Animal과 Dog 타입 모두 적용.
FixtureMonkey fixtureMonkey = FixtureMonkey.builder()
    .pushAssignableTypeArbitraryIntrospector(Animal.class, customIntrospector)
    .build();

2.1.3. pushArbitraryIntrospector

MatcherOperator<ArbitraryIntrospector>를 직접 구현하고, 해당 MatcherOperator가 적용된다.

사용자가 정의한 복잡한 매칭 로직을 적용할 수 있다.

pushArbitraryIntrospector의 예제코드는 3.에서 기술한다.

2.2. 성능상 이점

ArbitraryIntrospector 설정은 JavaArbitraryIntrospector(-> JavaTimeArbitraryIntrospector -> ... -> fallbackIntrospector)보다 이전에 처리된다.

참고 소스코드 ⬇️

/*
FixtureMonkeyOptionsBuilder.java
line 637 ~ 651
*/

// JavaDefaultArbitrary의 Introspector들
ArbitraryGenerator defaultArbitraryGenerator = 
	defaultIfNull(this.defaultArbitraryGenerator, this.javaDefaultArbitraryGeneratorBuilder::build);

// 사용자 정의 ArbitraryIntrospector들
List<ArbitraryIntrospector> typedArbitraryIntrospectors = arbitraryIntrospectors
	.getList()
	.stream()
	.map(TypedArbitraryIntrospector::new)
	.collect(Collectors.toList());

ArbitraryGenerator introspectedGenerator =
	new IntrospectedArbitraryGenerator(new MatchArbitraryIntrospector(typedArbitraryIntrospectors));

// 사용자 정의 ArbitraryIntrospector가 JavaDefaultArbitrary 보다 우선된다.
defaultArbitraryGenerator = new MatchArbitraryGenerator(
	Arrays.asList(introspectedGenerator, defaultArbitraryGenerator)
);

즉, 커스텀한 ArbitraryIntrospector가 Introspector 체인의 가장 앞에 추가된다.

ArbitraryIntrospector에서 객체 생성에 성공하면

objectIntrospector를 비롯한 여러 기본 Introspectors 를 거치지 않으므로

불필요한 인트로스펙터 호출을 피하고 오버헤드를 줄일 수 있다.

2.3. 사용 시 유의사항

ArbitraryIntrospector(pushExactTypeArbitraryIntrospector, pushAssignableTypeArbitraryIntrospector, pushArbitraryIntrospector)는 가장 마지막에 등록한 설정이 가장 먼저 적용되는 선입 후출(First-In, Last-Out) 구조이다.

가장 높은 우선순위를 두어야 하는 설정은 가장 마지막에 작성한다.

FixtureMonkey fixtureMonkey = FixtureMonkey.builder()
    // 가장 낮은 우선순위로 두고 싶은 설정을 먼저 작성한다. (JavaDefaultIntrospector보단 우선됨)
    .pushAssignableTypeArbitraryIntrospector(LowPriority.class, customIntrospector3)
    // 가장 높은 우선순위로 두고 싶은 설정
    .pushAssignableTypeArbitraryIntrospector(HighPriority.class, customIntrospector1)
    .objectIntrospector(...)
    .build();

※ List 형식으로 여러 개를 한번에 등록할 순 없음

3. 매개변수화된 클래스(parameterized class)를 등록하는 방법

이전 아티클에서도 다루었던 Range.class를 예시로 기술한다.

Range class 문서: https://guava.dev/releases/19.0/api/docs/com/google/common/collect/Range.html

Range는 Range<C extends Comparable> 형식이며

이 글에서는 제네릭 타입으로 Instant를 사용하여 Range<Instant> 를 사용한다.

위와 같은 Parameterized Class는 pushArbitraryIntrospector로만 등록할 수 있다.

예제 코드는 다음과 같다.

    private final FixtureMonkey FIXTURE_MONKEY = FixtureMonkey.builder()
            .pushArbitraryIntrospector(
                    new MatcherOperator<>(
                            new AssignableTypeMatcher(Range.class),
                            rangeInstantArbitraryIntrospector
                    )
            )
            .build();

3.1. 제네릭 개수 체크

매개변수화된 클래스의 제네릭 타입 개수까지 미리 검증하도록 설정할 수 있다.

예제 코드는 다음과 같다.

    private final FixtureMonkey FIXTURE_MONKEY = FixtureMonkey.builder()
            .pushArbitraryIntrospector(
                    new MatcherOperator<>(
                            new AssignableTypeMatcher(Range.class).intersect(new SingleGenericTypeMatcher()),
                            rangeInstantArbitraryIntrospector
                    )
            )
            .build();

Range<C> 는 하나의 제네릭을 가지므로 `.intersect(new SingleGenericTypeMatcher())` 를 설정한다.

다른 예로,

커스텀한 Pair<T, T> 와 같이 두개의 제네릭을 가진다면 `.intersect(new DoubleGenericTypeMatcher())` 를 설정한다.

현재(25.10.19) 기준 세 개의 제네릭 매칭까지 지원한다. (`TripleGenericTypeMatcher`)

[Fixture Monkey] 불변 객체를 위한 사용자 정의 인트로스펙터 예제 코드 - 기초편

the0 — Mon, 6 Oct 2025 12:11:17 +0900

불변 객체(`google.common.collect.Range`)를 위한 사용자 정의 인트로스펙터 예제 코드입니다.

사용 버전: 1.1.11

⬇️ 코드만 먼저 보기

/**
 * Range<Instant> 타입에 대한 값을 반환하는 사용자 정의 인트로스펙터 예제
 */
public class RangeInstantArbitraryIntrospector implements ArbitraryIntrospector {
    @Override
    public ArbitraryIntrospectorResult introspect(ArbitraryGeneratorContext context) {
	// 1단계: 이 인트로스펙터가 이 타입을 처리해야 하는지 확인
    	// Range.class 추출
        Property property = context.getResolvedProperty();
        Class<?> type = Types.getActualType(property.getType());
        // Instant.class 추출
        List<AnnotatedType> typeArguments = Types.getGenericsTypes(property.getAnnotatedType());
        Class<?> genericType = typeArguments.isEmpty() ? null : Types.getActualType(typeArguments.getFirst());

        if (!type.equals(Range.class)
                || typeArguments.size() != 1
                || !genericType.equals(Instant.class)) {
            // 대상 타입이 아니면 다른 인트로스펙터가 처리하도록 함
            return ArbitraryIntrospectorResult.NOT_INTROSPECTED;
        }
        
        // ===== 난수 생성 예시 =====
        Instant baseTime = Instant.now();

        long offset1 = (long) ((Math.random() * 730) - 365);
        long offset2 = (long) ((Math.random() * 730) - 365);

        Instant time1 = baseTime.plus(offset1, ChronoUnit.DAYS);
        Instant time2 = baseTime.plus(offset2, ChronoUnit.DAYS);

        Instant startTime = time1.isBefore(time2) ? time1 : time2;
        Instant endTime = time1.isBefore(time2) ? time2 : time1;
        // ===== 난수 생성 예시 =====

        Range<Instant> rangeValue = Range.closed(startTime, endTime);
		
        // 상수 값 반환
        return new ArbitraryIntrospectorResult(
                CombinableArbitrary.from(rangeValue)
        );
    }
}

// 사용자 정의 인트로스펙터 생성
ArbitraryIntrospector rangeInstantArbitraryIntrospector = new RangeInstantArbitraryIntrospector();

// 사용자 정의 인트로스펙터를 먼저 시도하고,
// 적용되지 않으면 표준 인트로스펙터로 대체하는 Fixture Monkey 생성
FixtureMonkey fixtureMonkey = FixtureMonkey.builder()
    .objectIntrospector(new FailoverIntrospector(
        Arrays.asList(
            rangeInstantArbitraryIntrospector,  // 사용자 정의 인트로스펙터를 먼저 시도
            ConstructorPropertiesArbitraryIntrospector.INSTANCE,
            BuilderArbitraryIntrospector.INSTANCE,
            FieldReflectionArbitraryIntrospector.INSTANCE,
            BeanArbitraryIntrospector.INSTANCE
        )
    ))
    .build();

Fixture Monkey에 내장되어 있는 인트로스펙터는 다음과 같은 대상 클래스를 지원한다.

Setter가 있는 클래스
생성자가 있는 불변 클래스
혼합 필드 접근 방식의 클래스
빌더 패턴을 사용하는 클래스

인트로스펙터

인트로스펙터란 무엇인가요? # Fixture Monkey의 인트로스펙터(Introspector)는 테스트 객체를 생성하는 방법을 결정하는 도구입니다. 테스트 객체를 생성하는 “공장"이라고 생각하면 됩니다. 인트로

naver.github.io

하지만 예를 들어

Google Guava 라이브러리의 Range 타입이나

https://guava.dev/releases/19.0/api/docs/com/google/common/collect/Range.html

Java Inet4Address, Inet6Address 타입은

https://docs.oracle.com/javase/8/docs/api/java/net/Inet4Address.html

정적 팩터리 메서드로 생성되는 불변 객체이다.

즉, setter도 없고, public 생성자도 없고, 필드 직접 접근도 불가능하다.

불변 객체도 랜덤 테스트 객체를 지원하기 위해서는 사용자 정의 인트로스펙터를 작성해야 한다.

이 글에서는 Range<Instant> 에 대한 사용자 정의 인트로스펙터를 소개한다.

참고: Fixture Monkey 공식 문서 > 객체 생성 > 사용자 정의 인트로스펙터 만들기

https://naver.github.io/fixture-monkey/v1-1-0-kor/docs/generating-objects/custom-introspector/

import java.time.Instant;
import com.google.common.collect.Range;

public record Foo(
	...
	Range<Instant> period,
 	...
) {
}

// 예시: ["2025-10-06 01:00:00.000+00","2025-10-06 09:00:00.000+00"]

Foo 객체 내에 [Instant, Instant] 를 담아 기간을 나타내는 period 필드가 있다.

내장 인트로스펙터만 사용하면 다음과 같은 에러가 발생한다.

// BuilderArbitraryIntrospector가 아니더라도 모든 Intraspector가 아래와 같은 에러를 출력한다.
WARN  "BuilderArbitraryIntrospector" is failed to introspect "example.demo.foo.model.Foo" type.

Failed to generate type "Foo"
java.lang.IllegalArgumentException: Failed to generate type "Foo"

Foo 객체를 만들지 못하는 이유는 내장 인트로스펙터로는 Range<Instant>를 생성하지 못하기 때문이다.

Range 타입을 지원하지 않는 이유는 해당 타입이 불변 객체이기 때문이다.

Range에 대한 공식 문서를 참고해서 기존 인트로스펙터의 지원 여부를 판단할 수 있다.

https://guava.dev/releases/19.0/api/docs/com/google/common/collect/Range.html

Setter가 있는 클래스 -> ❎
생성자가 있는 불변 클래스 -> ❎
혼합 필드 접근 방식의 클래스 -> ❎
빌더 패턴을 사용하는 클래스 -> ❎

그렇다면 공식 문서를 참고해 사용자 정의 인트로스펙터를 만들자!

https://naver.github.io/fixture-monkey/v1-1-0-kor/docs/generating-objects/custom-introspector/

/**
 * Range<Instant> 타입에 대한 값을 반환하는 사용자 정의 인트로스펙터 예제
 */
public class RangeInstantArbitraryIntrospector implements ArbitraryIntrospector {
    @Override
    public ArbitraryIntrospectorResult introspect(ArbitraryGeneratorContext context) {
	// 1단계: 이 인트로스펙터가 이 타입을 처리해야 하는지 확인
    	// Range.class 추출
        Property property = context.getResolvedProperty();
        Class<?> type = Types.getActualType(property.getType());
        // Instant.class 추출
        List<AnnotatedType> typeArguments = Types.getGenericsTypes(property.getAnnotatedType());
        Class<?> genericType = typeArguments.isEmpty() ? null : Types.getActualType(typeArguments.getFirst());

        if (!type.equals(Range.class)
                || typeArguments.size() != 1
                || !genericType.equals(Instant.class)) {
            // 대상 타입이 아니면 다른 인트로스펙터가 처리하도록 함
            return ArbitraryIntrospectorResult.NOT_INTROSPECTED;
        }
        
        // ===== 난수 생성 예시 =====
        Instant baseTime = Instant.now();

        long offset1 = (long) ((Math.random() * 730) - 365);
        long offset2 = (long) ((Math.random() * 730) - 365);

        Instant time1 = baseTime.plus(offset1, ChronoUnit.DAYS);
        Instant time2 = baseTime.plus(offset2, ChronoUnit.DAYS);

        Instant startTime = time1.isBefore(time2) ? time1 : time2;
        Instant endTime = time1.isBefore(time2) ? time2 : time1;
        // ===== 난수 생성 예시 =====

        Range<Instant> rangeValue = Range.closed(startTime, endTime);
		
        // 상수 값 반환
        return new ArbitraryIntrospectorResult(
                CombinableArbitrary.from(rangeValue)
        );
    }
}

인트로스펙터를 커스텀한 후에는

사용할 수 있도록 설정을 해야한다.

// 사용자 정의 인트로스펙터 생성
ArbitraryIntrospector rangeInstantArbitraryIntrospector = new RangeInstantArbitraryIntrospector();

// 사용자 정의 인트로스펙터를 먼저 시도하고,
// 적용되지 않으면 표준 인트로스펙터로 대체하는 Fixture Monkey 생성
FixtureMonkey fixtureMonkey = FixtureMonkey.builder()
    .objectIntrospector(new FailoverIntrospector(
        Arrays.asList(
            rangeInstantArbitraryIntrospector,  // 사용자 정의 인트로스펙터를 먼저 시도
            ConstructorPropertiesArbitraryIntrospector.INSTANCE,
            BuilderArbitraryIntrospector.INSTANCE,
            FieldReflectionArbitraryIntrospector.INSTANCE,
            BeanArbitraryIntrospector.INSTANCE
        )
    ))
    .build();

다른 인트로스펙터 설정 방식은 아래의 아티클에서 기술한다.

(CustomArbitraryIntrospector를 등록하는 여러 방법)

[Fixture Monkey] CustomArbitraryIntrospector를 등록하는 여러 방법

[Fixture Monkey] 불변 객체를 위한 사용자 정의 인트로스펙터 예제 코드 - 기초편불변 객체(`google.common.collect.Range`)를 위한 사용자 정의 인트로스펙터 예제 코드입니다.사용 버전: 1.1.11 ⬇️ 코드만

the0.tistory.com

이후엔 Range<Instant> 타입이 담긴 Foo 객체가 잘 생성되어

테스트 실행 시 에러가 발생하지 않는다.

하지만!

이 예시 클래스인 Range.class 처럼 일부 클래스는

giveMeBuilder().set("period", range) 의 값이 적용되지 않는 문제가 발생할 수도 있다.

이에 관한 내용은 다음 아티클에서 기술한다.

[Fixture Monkey] giveMeBuilder().set()의 값이 적용되지 않음

1. 문제 상황Fixture Monkey 1.1.11 버전 사용 Google Guava 라이브러리의 Range.class는 giveMeBuilder().set()으로 value가 적용되지 않음(String, int, enum 등 자바 기본 자료형은 문제 없음)@Testvoid test_set_range() { Range ta

the0.tistory.com

[Spring Data JPA] 트랜잭션 끝나도 DB 커넥션 릴리즈 안됨 (feat. OSIV)

the0 — Fri, 27 Jun 2025 02:27:57 +0900

개발 환경:

Spring 3.4.4, Spring Data JPA(Hibernate 6.6.11)
한 메서드 내에 DB 접근와 SSE send를 하고 있다.
SSE가 tomcat thread로 동기 처리된다. (원래는 비동기 처리해야함. 커넥션 점유 테스트를 위해 이렇게 둠.)
커넥션 점유를 5초 이상하면 로그를 출력하도록 설정했다.

문제 상황

해당 메서드(~=스레드) 에서 커넥션을 계속 점유하고 있다는 로그가 출력된다.
`maximum-pool-size` 를 초과하면 에러가 발생한다.

사건의 발단이 된 코드는 다음과 같다.

코드가 길어서 축약했다.

public SseEmitter subscribe(AuthUser authUser) {
    Long userId = userRepository.findByOauthId(authUser.getOauthId())
            .orElseThrow(() -> new BusinessExceptionHandler("유저가 존재하지 않습니다.", ErrorCode.NOT_FOUND_ERROR))
            .getId();

    SseEmitter emitter = new SseEmitter(TIMEOUT);
    emitters.put(userId, emitter);
    ...
    
    try {
        emitter.send(SseEmitter.event().name("connect").data("SSE 연결 완료"));
    } catch (IOException e) {
        emitter.complete();
        emitters.remove(userId);
    }
    return emitter;
}

spring:
    hikari:
      leak-detection-threshold: 5000

기존에 알고 있던 사실:

userRepository.findByOauthId 를 실행하기 위해 엔티티 매니저가 DB 커넥션을 획득한다.

userRepository.findByOauthId 트랜잭션이 종료됨에 따라 엔티티 매니저가 DB 커넥션을 릴리즈한다.

의문점은 다음과 같다.

userRepository.findByOauthId 트랜잭션이 종료됨에 따라
엔티티 매니저가 DB 커넥션을 릴리즈해야하는데..

왜 계속 점유를 하고 있는거지?

의문점 해결:

먼저, OSIV 에 대해서 이해를 해야한다.

참고

0. 검색 키워드

open-in-view
OSIV

Spring Boot 에는 open-in-view 설정의 기본 값이 true이다.

나는 아무 설정을 하지 않았으므로 당연히 `open-in-view=true` 로 설정되어 있었다.

이 값이 true이면,

JPA의 EntityManager는 클라이언트에게 HTTP 응답을 완료할 때까지 열려있다.(= 응답이 끝나고 나서 em.close()를 한다.)
Hibernate x.x 에서 DB의 conn.close()는 EntityManger.close() 가 동작하는 과정에서 내부적으로 conn.close()가 실행된다.
위의 두 내용을 종합하면 => DB connection은 HTTP 응답 반환 이후에 close 된다.
SSE 를 동기 처리한 코드에서는 위의 이유+`SSE 는 close 되기 전까지 thread를 물고 있는다.` 라는 복합 이유로 인해 DB 커넥션이 계속 점유되고 있는 것이다.

그래서 트랜잭션이 끝나도 DB 커넥션이 반납되지 않았던 것이다!

추가 분석:

왜, 어떻게 세션이 끝날 때까지 커넥션이 붙잡혀 있는지 궁금했다.

hibernate를 비롯한 jpa 라이브러리 코드를 추척했다.

커넥션의 획득과 해제 시점 설정 관련된 코드가 hibernate.connection.handling_mode 임을 알게 되었다.
출처: 챗지피티, https://jaimemin.tistory.com/2704

* 위의 블로그는 시퀀스 다이어그램도 있어서 읽어보면 좋다.

+ hibernate의 handling_mode 에 관한 자료가 많이 없다...

Spring이 Hibernate를 부트스트래핑하는 과정을 배제하고

일단 Hibernate 자체만을 먼저 분석한다.

JdbcSettings.java에서 connection_handling의 기본 값이

DELAYED_ACQUISITION_AND_RELEASE_AFTER_TRANSACTION

임을 알 수 있다. 이는 hibernate 5.2+ 부터 적용된다.

CONNECTION_HANDLING 의 종류가 무엇이 있는지는

PhysicalConnectionHandlingMode.java에서 확인할 수 있다.

한국어로 번역해서 정리하면 다음과 같다.

PhysicalConnectionHandlingMode	주석 번역
IMMEDIATE_ACQUISITION_AND_HOLD	세션이 열리는 즉시 획득되며 세션이 닫힐 때까지 유지된다. 이는 유일하게 유효한 조합이며 커넥션을 즉시 획득하는 것을 포함한다.
DELAYED_ACQUISITION_AND_HOLD	필요한 즉시 획득되며 세션이 닫힐 때까지 유지된다. 이는 원래 Hibernate 동작이다.
DELAYED_ACQUISITION_AND_RELEASE_AFTER_STATEMENT	필요한 즉시 획득되며 각 명령문이 실행된 후 해제된다.
DELAYED_ACQUISITION_AND_RELEASE_BEFORE_TRANSACTION_COMPLETION	필요한 즉시 획득되며, 커밋 또는 롤백 전에 해제된다.
DELAYED_ACQUISITION_AND_RELEASE_AFTER_TRANSACTION	필요한 즉시 획득되며, 각 트랜잭션이 완료된 후 해제된다.

의문점 하나, (애매하게 해결됨)

DELAYED_ACQUISITION_AND_HOLD 이 "This is the original Hibernate behavior" 라며 기본 동작이라는 주석이 적혀 있는데,

JdbcSettings.java 에는 DELAYED_ACQUISITION_AND_RELEASE_AFTER_TRANSACTION가 default 라고 나와 있다.

Q. the original behavior != default behavior 인건가?

https://hibernate.atlassian.net/browse/HHH-5184?focusedCommentId=74692

이 링크에서 DELAYED_ACQUISITION_AND_HOLD 를 "original legacy behavior" 라고 표현한다.

DELAYED_ACQUISITION_AND_HOLD를 the original behavior라고 표현하는 것에 대해

default behavior 보단 legacy behavior 로 이해하면 될 것 같다.

아무튼 JdbcSettings.java의 CONNECTION_HANDLING 은 JdbcEnvironmentInitator.java에서 다음과 같이 사용된다.

JdbcEnvironmentInitator.java의 TemporaryJdbcSessionOwner() 메서드 내부 로직의 일부를 캡쳐했다.

hibernate.connection.handling_mode 를 application.yml에서 직접 설정하지 않았으므로

hibernate.connection.handling_mode 를 설정하는 방법은 다음과 같다.
spring:
  jpa:
    properties:
      hibernate.connection.handling_mode=

specifiedHandlingMode 는 null 이고 이에 따라 getDefaultConnectionHandlingMode() 가 실행된다.

JdbcResourceLocalTransactionCoordinatorBuilderImpl.java의 getDefaultConnectionHandlingMode() 는 다음과 같다.

이에 따라

JdbcSettings.java에서 connection_handling의 기본 값이 DELAYED_ACQUISITION_AND_RELEASE_AFTER_TRANSACTION 라는 증명을 종료한다.

여기까지 왔으면 HIbernate 는 DELAYED_ACQUISITION_AND_RELEASE_AFTER_TRANSACTION 설정

"DB 커넥션은 필요한 즉시 획득되며, 각 트랜잭션이 완료된 후 해제된다." 정책을 따름을 알 수 있다.

하지만 이 아티클 초반의 '문제 정의'에 따르면

DB 커넥션은 트랜잭션이 완료된 이후에도 점유되고 있었다.

즉, 실제로는 DELAYED_ACQUISITION_AND_HOLD 정책을 따르고 있는 것이다.

이번에는 Spring이 Hibernate를 부트스트래핑하는 과정에서 CONNECTION_HANDING 설정이 어떻게 바뀌는지 분석한다.

Hibernate가 부트스트래핑 될때 중점적으로 봐야하는 파일은 HibernateJpaVendorAdapter.java 이다.

이름대로 HibernateJpaVendorAdapter는 Hibernate를 JPA 구현체로 설정하기 위한 어댑터 클래스이다.

HibernateJpaVendorAdapter를 사용하면 Hibenate의 설정을 JPA에 자동 적용해준다.

JPA는 추상화된 데이터 접근을 제공하기 때문에 특정 벤더에 종속적이지 않다.
HIbernate는 JPA의 구현체 중 하나이다.
출처: https://dev-coco.tistory.com/74

HibernateJpaVendorAdapter 클래스에서 중점적으로 봐야하는 메서드는

setPrepareConnection(boolean prepareConnection) 이다.

prepareConnection 값은 true 가 default 값이며

이는 Spring 4.3.1 부터 적용되고 있다.

메서드 주석에 의하면 해당 메서드는

격리 수준과 읽기 전용 여부 같은 트랜잭션 특성 정보를 JDBC 커넥션에 직접 적용할지 결정한다.
prepareConnection=true 인 경우 CONNECTION_HANDLING 값은 DELAYED_ACQUISITION_AND_HOLD로 적용된다.

그럼 Spring이 setPrepareConnection() 메서드를 Hibernate에 hibernate.connection.handling_mode=DELAYED_ACQUISITION_AND_HOLD를 어떻게, 어디서 전달하느냐를 따라가본다.

코드가 길어서 캡쳐 대신 복붙으로 가져왔다.

동일한 HibernateJpaVendorAdapter 클래스 내부의 메서드이다.

@Override
public Map<String, Object> getJpaPropertyMap(PersistenceUnitInfo pui) {
    return buildJpaPropertyMap(this.jpaDialect.prepareConnection && // 1번 ✅
          pui.getTransactionType() != PersistenceUnitTransactionType.JTA);
}

@Override
public Map<String, Object> getJpaPropertyMap() {
    return buildJpaPropertyMap(this.jpaDialect.prepareConnection); // 1번 ✅
}

private Map<String, Object> buildJpaPropertyMap(boolean connectionReleaseOnClose) {
    Map<String, Object> jpaProperties = new HashMap<>();

    // ... 다른 설정들 jpaProperties.put()

    if (connectionReleaseOnClose) {
       jpaProperties.put(AvailableSettings.CONNECTION_HANDLING,
             PhysicalConnectionHandlingMode.DELAYED_ACQUISITION_AND_HOLD); // 2번 ✅
    }

    // For SpringBeanContainer to be called on Hibernate 6.2
    jpaProperties.put("hibernate.cdi.extensions", "true");

    return jpaProperties;
}

1. 1번 ✅ 에서 prepareConnection = true 로 인자가 넘어간다.

2. buildJpaPropertyMap의 파라미터 connectionReleaseOnClose 는 true를 받는다.

3. if(connectionReleaseOnClose) 조건문은 true로, 조건문 내부가 실행된다.

4. 1번 ✅ 에서 handling mode 값이 DELAYED_ACQUISITION_AND_HOLD 로 설정되는 것을 확인할 수 있다.

아까 언급했던 JdbcEnvironmentInitator.java#TemporaryJdbcSessionOwner() 내부 로직을 확인한다.

JpaPropertiesMap 에 CONNECTION_HANDLING 값이 DELAYED_ACQUISITION_AND_HOLD 으로 명시되어 설정되었으므로

Hibernate가 부트스트래핑되는 과정에서 specifiedHandlingMode는 더이상 null 값이 아니게 되고, specifiedHandlingMode(DELAYED_ACQUISITION_AND_HOLD) 으로 설정된다.

이에 따라

open-in-view 가 true이면 DB connection은 EntityManager 가 종료되기 전까지 유지된다는 증명을 완료한다.

추가 참고자료

https://karsei.pe.kr/46

[Spring] JPA 와 Mybatis 동시 사용 시 Connection Deadlock 벗어난 이슈 정리

계기PHP 에서 Java 로 작업을 진행하면서 기존에 작성했던 Query 문을 사용해야 할 필요가 생었겼다. 근데 한번에 효율적으로 데이터들을 불러오려고 작성된 Query 를 사용하려다보니 우선은 Query 문

karsei.pe.kr

[Spring Data JPA] 서비스 레이어의 어느 메서드에 @Transactional을 안붙이면?

the0 — Fri, 27 Jun 2025 01:38:48 +0900

Spring 3.x, Spring Data JPA(+ Hibernate) 를 쓰는 환경이다.

예시 코드 설명:

exampleService 클래스의 한 메서드인 example() 이다.
example()은 authUser 를 인자값으로 받아 이를 userRepository에 Read로 접근한다.

public exampleResponse example(AuthUser authUser) {
    User user = userRepository.findByOauthId(authUser.getOauthId())
            .orElseThrow(() -> new BusinessExceptionHandler("유저가 존재하지 않습니다.", ErrorCode.NOT_FOUND_ERROR));
    ...
}

내가 가진 의문점은 다음과 같다.

DB에 접근하는 코드를 가진 메서드에 @Transactional을 붙이지 않으면
누가, 언제 DB 커넥션을 획득하고 릴리즈하는가?

이전에 내가 알고 있던 사실은 다음과 같다.

@Transactional 어노테이션이 없는 Repository 직접 접근의 경우
각 쿼리( 예: repository.method() ) 호출마다 독립적인 트랜잭션이 생성되고 쿼리 실행이 완료되면 커넥션이 반환된다.

이 아티클은 위의 내용이 참인지, 그리고 어떻게 동작하는지 알아본다.

(위의 코드에 이어서 설명) UserRepository 처럼 개발자가 정의하는 커스텀 Repository 인터페이스는,

Spring Data JPA가 SimpleJpaRepository를 기반으로 런타임에 동적으로 구현한다.

참고

0. 검색 키워드

SimpleJpaRepository 프록시

1. 초반 부분, Reflection 설명 전까지

https://pingpongdev.tistory.com/25

Spring Data JPA 는 어떻게 interface 만으로도 동작할까? (feat. reflection, proxy)

Spring Data JPA를 공부하면서 궁금한 것이 있었습니다. public interface MemberRepository extends JpaRepository { List findAllByName(String name); } 위와 같이 MemberRepository는 인터페이스고, @Repository 애노테이션을 붙여

pingpongdev.tistory.com

SimpleJpaRepository 클래스에는 여러 메서드들이 구현되어 있다.

메서드 종류는 IDE를 통해서 볼 수도 있고 혹은 공식문서(https://docs.spring.io/spring-data/jpa/docs/current/api/org/springframework/data/jpa/repository/support/SimpleJpaRepository.html) 가 있다.

예를 들어, 자주 사용하는 save(), findAll(), delete() 등 기본적인 CRUD 메서드들이 있다.

중요하게 봐야하는 부분은 다음과 같다.

SimpleJpaRepository 클래스 레벨에서 @Transactional(readOnly = true) 이 적용되어 있다!
각 메서드 별로 @Transactional 등 적절한 트랙잭션 설정이 되어 있다!

@Repository
@Transactional(readOnly = true) // ✅
public class SimpleJpaRepository<T, ID> implements JpaRepositoryImplementation<T, ID> {
	
    @Override
	@Transactional // ✅
	public <S extends T> S save(S entity) {

		Assert.notNull(entity, ENTITY_MUST_NOT_BE_NULL);

		if (entityInformation.isNew(entity)) {
			entityManager.persist(entity);
			return entity;
		} else {
			return entityManager.merge(entity);
		}
	}
    
    @Override
	@Transactional // ✅
	public void deleteById(ID id) {

		Assert.notNull(id, ID_MUST_NOT_BE_NULL);

		findById(id).ifPresent(this::delete);
	}

}

결론

이전에 내가 알고 있던 사실은 사실이 맞다.

@Transactional 어노테이션이 없는 Repository 직접 접근의 경우
각 쿼리( 예: repository.method() ) 호출마다 독립적인 트랜잭션이 생성되고 쿼리 실행이 완료되면 커넥션이 반환된다.

내가 가진 의문점에 하나씩 대답한다.

DB에 접근하는 코드를 가진 메서드에 @Transactional을 붙이지 않으면
누가, 언제 DB 커넥션을 획득하고 릴리즈하는가?

언제 DB 커넥션을 획득하고 릴리즈하는가?

기존에 알고 있었을 트랜잭션 관련 사실:
@Transactional 이 수행됨에 따라 DB 커넥션을 획득하고, 트랜잭션이 종료됨에 따라 DB 커넥션이 릴리즈된다.

SimpleJpaRepository 클래스 내에 각 CRUD 메서드들은 @Transactional 이 적용되어 있다.

예를 들어 Service layer의 어느 메서드 내에 customRepository.save() 를 한다.
이 save() 메서드는 내부적으로 @Transactional이 적용되어 트랜잭션 수행된다.
@Transactional이 수행됨에 따라 DB 커넥션을 획득하고, 종료됨에 따라 커넥션이 릴리즈된다.

누가 DB 커넥션을 획득하고 릴리즈하는가?

JpaTransactionManager에 의해 entityManagerFactory로부터 엔티티 매니저가 생성된다.
각 엔티티 매니저는 커넥션 풀에 있는 한 커넥션을 점유해 DB에 접근한다.
이후 엔티티 매니저가 커넥션을 릴리즈한다.
(일반 개념. 이 아티클 주제인 `@Transactional을 서비스 레이어 메서드에 붙/안붙 차이` 와는 직접 관련X. )

[Spring Data JPA] 커넥션은 언제 릴리즈 될까 (w/ @Transactional)

the0 — Thu, 26 Jun 2025 16:53:38 +0900

Spring Data JPA 와 Hibernate를 사용하고

@Transactional 어노테이션이 명시된 서비스 레이어의 메서드가 존재한다고 가정한다.

이 아티클은 connection.close()가 실행되는 step을 트레이싱한다.

AbstractPlatformTransactionManager에서는

doCommit() 혹은 doRollback() 이후 doCleanupAfterCompletion()이 실행된다.

레퍼런스

0. AbstractPlatformTransactionManager 의 doCleanupAfterCompletion() 설명

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/support/AbstractPlatformTransactionManager.html#doCleanupAfterCompletion(java.lang.Object)

1. 시퀀스 다이어그램 참고

https://dhsim86.github.io/web/2017/11/04/spring_custom_transactionmanager-post.html

Dongho Sim's dev story|스프링 Custom TransactionManager 구현

Stats: comments

dhsim86.github.io

2. 인프런 답변 참고

https://www.inflearn.com/community/questions/589711/커넥션-종료?srsltid=AfmBOop-yun7Z8Cynu3ySNOhy_9zlrXA2MObvA-5HD7wsnlNVKQbdEB4

Spring Data JPA 를 사용하고 있으므로,

현재 사용되는 트랜잭션 매니저는 PlatformTransactionManager의 구현체 중 하나인 JpaTransactionManager이다.

JpaTransactionManager.java의 doCleanupAfterCompletion() 코드는 다음과 같다.

@Override
protected void doCleanupAfterCompletion(Object transaction) {
    JpaTransactionObject txObject = (JpaTransactionObject) transaction;

    // Remove the entity manager holder from the thread, if still there.
    // (Could have been removed by EntityManagerFactoryUtils in order
    // to replace it with an unsynchronized EntityManager).
    if (txObject.isNewEntityManagerHolder()) {
        TransactionSynchronizationManager.unbindResourceIfPossible(obtainEntityManagerFactory());
    }
    txObject.getEntityManagerHolder().clear();

    // Remove the JDBC connection holder from the thread, if exposed.
    if (getDataSource() != null && txObject.hasConnectionHolder()) {
        TransactionSynchronizationManager.unbindResource(getDataSource());
        ConnectionHandle conHandle = txObject.getConnectionHolder().getConnectionHandle();
        if (conHandle != null) {
            try {
                getJpaDialect().releaseJdbcConnection(conHandle,
                        txObject.getEntityManagerHolder().getEntityManager());
            }
            catch (Throwable ex) {
                // Just log it, to keep a transaction-related exception.
                logger.error("Failed to release JDBC connection after transaction", ex);
            }
        }
    }

    getJpaDialect().cleanupTransaction(txObject.getTransactionData());

    // Remove the entity manager holder from the thread.
    if (txObject.isNewEntityManagerHolder()) {
        EntityManager em = txObject.getEntityManagerHolder().getEntityManager();
        if (logger.isDebugEnabled()) {
            logger.debug("Closing JPA EntityManager [" + em + "] after transaction");
        }
        EntityManagerFactoryUtils.closeEntityManager(em); //❗️❗️❗️
    }
    else {
        logger.debug("Not closing pre-bound JPA EntityManager after transaction");
    }
}

위 메서드에서 DB connection 릴리즈와 관련이 있는 코드는 다음과 같다.

// 마지막 if문 내부에 있음
EntityManagerFactoryUtils.closeEntityManager(em);

EntityManagerFactoryUtils.java의 closeEntityManager() 코드는 다음과 같다.

/**
 * Close the given JPA EntityManager,
 * catching and logging any cleanup exceptions thrown.
 * @param em the JPA EntityManager to close (may be {@code null})
 * @see jakarta.persistence.EntityManager#close()
 */
public static void closeEntityManager(@Nullable EntityManager em) {
    if (em != null) {
        try {
            if (em.isOpen()) {
                em.close(); //❗️❗️❗️
            }
        }
        catch (Throwable ex) {
            logger.error("Failed to release JPA EntityManager", ex);
        }
    }
}

위 메서드에서 DB connection 릴리즈와 관련이 있는 코드는 다음과 같다.

em.close();

Spring Data JPA + Hibernate 를 사용하고 있으므로,

Hibernate가 JPA의 EntityManager 인터페이스를 Session으로 구현하고,

Session은 다시 내부적으로 SessionImpl로 구현되고 있다.

SessionImpl.java 의 close() 코드는 다음과 같다.

closeWithoutOpenChecks() 도 함께 가져왔다.

@Override
public void close() throws HibernateException {
    if ( isClosed() ) {
        if ( getFactory().getSessionFactoryOptions().getJpaCompliance().isJpaClosedComplianceEnabled() ) {
            throw new IllegalStateException( "Illegal call to #close() on already closed Session/EntityManager" );
        }

        log.trace( "Already closed" );
        return;
    }

    closeWithoutOpenChecks();
}

public void closeWithoutOpenChecks() throws HibernateException {
    if ( log.isTraceEnabled() ) {
        log.tracef( "Closing session [%s]", getSessionIdentifier() );
    }

    final EventManager eventManager = getEventManager();
    final HibernateMonitoringEvent sessionClosedEvent = eventManager.beginSessionClosedEvent();

    // todo : we want this check if usage is JPA, but not native Hibernate usage
    final SessionFactoryImplementor sessionFactory = getSessionFactory();
    try {
        if ( sessionFactory.getSessionFactoryOptions().isJpaBootstrap() ) {
            // Original hibernate-entitymanager EM#close behavior
            checkSessionFactoryOpen();
            checkOpenOrWaitingForAutoClose();
            if ( fastSessionServices.discardOnClose || !isTransactionInProgressAndNotMarkedForRollback() ) {
                super.close(); //❗️❗️❗️
            }
            else {
                //Otherwise, session auto-close will be enabled by shouldAutoCloseSession().
                prepareForAutoClose(); //❗️❗️❗️
            }
        }
        else {
            super.close(); //❗️❗️❗️
        }
    }
    finally {
        final StatisticsImplementor statistics = sessionFactory.getStatistics();
        if ( statistics.isStatisticsEnabled() ) {
            statistics.closeSession();
        }

        eventManager.completeSessionClosedEvent( sessionClosedEvent, this );
    }
}

위 메서드에서 DB connection 릴리즈와 관련있는 코드는 다음과 같다.

super.close();
// 혹은
prepareForAutoClose();

super.close() 명령이 실행되는 조건은 두 가지 경우가 있다.

1. sessionFactory.getSessionFactoryOptions().isJpaBootstrap() 이 false 인 경우

즉, JPA 부트스트랩 모드가 아닌 경우이다.

SessionFactoryOptions.java#isJpaBootstrap() 주석은 다음과 같다.

Was building of the SessionFactory initiated through JPA bootstrapping, or through Hibernate's native bootstrapping?
Returns:true indicates the SessionFactory was built through JPA bootstrapping;
false indicates it was built through native bootstrapping.

해석-
SessionFactory가 JPA 부트스트래핑으로 빌드되었으면 true,
HIbernate의 네이티브 부트스트래핑으로 빌드외었으면 false.

결론-
Spring Data JPA를 사용하면 isJpaBootstrap() == true이고, Hibernate만 직접 사용하면 false이다.

2. Hibernate가 JPA 부트스트랩 모드이면서 2-1 혹은 2-2 둘 중 하나만 만족해도 세션이 정리된다. (DB 커넥션 릴리즈)

2-1. fastSessionServices.discardOnClose == true -> 즉시 세션 정리

2-2. !isTransactionInProgressAndNotMarkedForRollback() == true

트랜잭션이 진행 중이지 않거나 rollback된 상태 둘 중 하나라도 참이면 된다.

내부 코드는 다음과 같다.

private boolean isTransactionInProgressAndNotMarkedForRollback() {
    if ( waitingForAutoClose ) {
        return getSessionFactory().isOpen()
            && getTransactionCoordinator().isTransactionActive( false );
    }
    else {
        return !isClosed()
            && getTransactionCoordinator().isTransactionActive( false );
    }
}

prepareForAutoClose() 명령이 실행되는 조건은 다음과 같다.

Hibernate가 JPA 부트스트랩 모드이면서 2-1 혹은 2-2 둘 다 만족하지 않는다.

2-1. fastSessionServices.discardOnClose == false

2-2. !isTransactionInProgressAndNotMarkedForRollback() == false

즉, isTransactionInProgressAndNotMarkedForRollback() == true.

트랜잭션이 진행 중이면서 아직 rollback 된 상태로 마킹되지 않음

prepareForAutoClose() 의 내부 코드는 AbstractSharedSessionContract.java에서 확인할 수 있다.

protected void prepareForAutoClose() {
    waitingForAutoClose = true;
    closed = true;
    // For non-shared transaction coordinators, we have to add the observer
    if ( !isTransactionCoordinatorShared ) {
        addSharedSessionTransactionObserver( transactionCoordinator );
    }
}

protected void addSharedSessionTransactionObserver(TransactionCoordinator transactionCoordinator) {
}

다만 addSharedSessionTransactionObserver는 해당 클래스에 구현되어있지 않고,

SessionImpl 에서 구현되어 있다.

구현체는 다음과 같다.

@Override
protected void addSharedSessionTransactionObserver(TransactionCoordinator transactionCoordinator) {
    transactionObserver = new TransactionObserver() {
        @Override
        public void afterBegin() {
        }

        @Override
        public void beforeCompletion() {
            if ( isOpen() && getHibernateFlushMode() !=  FlushMode.MANUAL ) {
                managedFlush();
            }
            actionQueue.beforeTransactionCompletion();
            beforeTransactionCompletionEvents();
        }

        @Override
        public void afterCompletion(boolean successful, boolean delayed) {
            afterTransactionCompletion( successful, delayed );
            if ( !isClosed() && autoClose ) {
                managedClose(); //❗️❗️❗️
            }
        }
    };
    transactionCoordinator.addObserver( transactionObserver );
}

위의 메서드에서 DB 커넥션 릴리즈와 관련있는 코드는 다음과 같다.

managedClose()

managedClose() 또한 SessionImpl 에 구현되어 있다.

private void managedClose() {
    log.trace( "Automatically closing session" );
    closeWithoutOpenChecks();
}

mangedClose()에서 호출하는 closeWithoutOpenChecks()는

SessionImpl#close() 내부에서 세션을 닫기 위해 호출하는 메서드 closeWithoutOpenChecks()와 동일하다.

즉, closeWithoutOpenChecks() -> prepareAutoClose() -> ... -> closeWithoutOpenChecks() 로 다시 돌아오게 된다.

그리고 다시 돌아왔을 때는 `!isTransactionInProgressAndNotMarkedForRollback() == true` 이므로 super.close()가 실행된다.

어찌되었든 호출된 super.close() 를 다시 파고든다.

SessionImpl.java#closeWithoutOpenChecks() 의 super.close()는 AbstractSharedSessionContract.java에 구현되어 있다.

@Override
public void close() {
    if ( closed && !waitingForAutoClose ) {
       return;
    }

    try {
       delayedAfterCompletion();
    }
    catch ( HibernateException e ) {
       if ( getFactory().getSessionFactoryOptions().isJpaBootstrap() ) {
          throw getExceptionConverter().convert( e );
       }
       else {
          throw e;
       }
    }

    if ( sessionEventsManager != null ) {
       sessionEventsManager.end();
    }

    if ( transactionCoordinator != null ) {
       removeSharedSessionTransactionObserver( transactionCoordinator );
    }

    try {
       if ( shouldCloseJdbcCoordinatorOnClose( isTransactionCoordinatorShared ) ) {
          jdbcCoordinator.close(); // ✅
       }
    }
    finally {
       setClosed();
    }
}

위의 메서드에서 DB 커넥션 릴리즈와 관련있는 코드는 다음과 같다.

jdbcCoordinator.close();

jdbcCoordinator는 인터페이스로, 이를 구현한 구현체는 JdbcCoordinatorImpl.java이다.

JdbcCoordinatorImpl.java의 close() 메서드는 다음과 같다.

@Override
public Connection close() {
    LOG.tracev( "Closing JDBC container [{0}]", this );
    Connection connection;
    try {
       if ( currentBatch != null ) {
          LOG.closingUnreleasedBatch();
          currentBatch.release();
       }
    }
    finally {
       connection = logicalConnection.close(); // ✅
    }
    return connection;
}

위의 메서드에서 DB 커넥션 릴리즈와 관련있는 코드는 다음과 같다.

connection = logicalConnection.close();

LogicalConnection는 인터페이스이다.

LogicalConnection

LogicalConnectionImplementor

AbstractLogicalConnectionImplementor
|

LogicalConnectionManagedImpl

LogicalConnectionManagedImpl에서 구현된 close() 는 다음과 같다.

@Override
public Connection close() {
    if ( closed ) {
       return null;
    }

    getResourceRegistry().releaseResources();

    log.trace( "Closing logical connection" );
    try {
       releaseConnection(); // ✅
    }
    finally {
       // no matter what
       closed = true;
       log.trace( "Logical connection closed" );
    }
    return null;
}

위의 메서드에서 DB 커넥션 릴리즈와 관련있는 코드는 다음과 같다.

releaseConnection()

해당 메서드는 동일한 클래스 내에 다음과 같이 구현되어 있다.

private void releaseConnection() {
    final Connection localVariableConnection = this.physicalConnection;
    if ( localVariableConnection == null ) {
       return;
    }

    // We need to set the connection to null before we release resources,
    // in order to prevent recursion into this method.
    // Recursion can happen when we release resources and when batch statements are in progress:
    // when releasing resources, we'll abort the batch statement,
    // which will trigger "logicalConnection.afterStatement()",
    // which in some configurations will release the connection.
    this.physicalConnection = null;
    try {
       try {
          getResourceRegistry().releaseResources();
          if ( !localVariableConnection.isClosed() ) {
             sqlExceptionHelper.logAndClearWarnings( localVariableConnection );
          }
       }
       finally {
          jdbcConnectionAccess.releaseConnection( localVariableConnection ); // ✅
       }
    }
    catch (SQLException e) {
       throw sqlExceptionHelper.convert( e, "Unable to release JDBC Connection" );
    }
    finally {
       observer.jdbcConnectionReleaseEnd();
    }
}

위의 메서드에서 DB 커넥션 릴리즈와 관련있는 코드는 다음과 같다.

jdbcConnectionAccess.releaseConnection( localVariableConnection );

jdbcConnectionAccess는 인터페이스로, 이를 구현한 구현체는 JdbcConnectionAccessConnectionProviderImpl이다.

JdbcConnectionAccessConnectionProviderImpl.java 의 releaseConnection() 은 다음과 같다.

@Override
public void releaseConnection(Connection connection) throws SQLException {
    if ( connection != this.jdbcConnection ) {
       throw new PersistenceException(
             String.format(
                   "Connection [%s] passed back to %s was not the one obtained [%s] from it",
                   connection,
                   JdbcConnectionAccessConnectionProviderImpl.class.getName(),
                   jdbcConnection
             )
       );
    }

    // Reset auto-commit
    if ( !wasInitiallyAutoCommit ) {
       try {
          if ( jdbcConnection.getAutoCommit() ) {
             jdbcConnection.setAutoCommit( false );
          }
       }
       catch (SQLException e) {
          log.info( "Was unable to reset JDBC connection to no longer be in auto-commit mode" );
       }
    }

    // Release the connection
    connectionProvider.closeConnection( jdbcConnection ); // ✅
}

위의 메서드에서 DB 커넥션 릴리즈와 관련있는 코드는 다음과 같다.

connectionProvider.closeConnection( jdbcConnection );

현재 Hikari CP를 사용하고 있으므로, 이를 기준으로 설명을 한다.

ConnectionProvider는 인터페이스로, 이를 구현한 구현체는 HikariConnectionProvider.java에 있다.

HikariConnectionProvider.java의 closeConnection() 은 다음과 같다.

@Override
public void closeConnection(Connection conn) throws SQLException
{
   conn.close();
}

conn.close() 도 이어서 트레이싱할 수 있긴하나 여기서 마친다.

[Github Actions] attempted methods [none password]

the0 — Tue, 27 May 2025 05:47:21 +0900

님 ssh 비밀번호에 '$' 가 포함되어 있지 않은지?????????????

상황:

- github actions 사용

- workflow 내용은 다음과 같음

      -  name: Deploy
         uses: appleboy/ssh-action@master
         with:
          host: ${{ env.SSH_HOST }}
          username: ${{ env.SSH_USER }}
          password: ${{ env.SSH_PASSWORD }}
          script: |
            ...

ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain 에러 발생

포인트

- 개발 서버는 문제 없이 접속 되었는데 운영 서버 접속 시에만 이런 에러가 발생함.

- PasswordAuthentication yes 로 설정되어있음

- 방화벽 문제 XXXXX

- secrets. 가 아닌 env.

문제 원인:

ssh password 값에 $이 존재한 것이 문제였다.

예를 들어 비밀번호가 ssh 접속을 위한 비밀번호가 abc1$2defghIj 라고 하자.

github actions는 echo로 환경변수를 설정할 때, shell이 $을 변수 참조 기호로 해석한다.

1. 따라서 비밀번호 abc1$2defghIj 에서 $2 를 "2라는 환경변수" 로 인식한다.

2. 그리고 (당연히 나는 2라는 환경변수를 설정하지 않았으니) 정의되지 않은 환경변수는 빈 문자열로 치환한다.

3. 결과적으로 abc1$2defghIj 에서 $2가 사라진 abc1defghIj 가 환경변수에 기록된다.

4. ssh 접속을 위한 password로 잘못된 값인 abc1defghIj 이 사용된다.

빨리 해결하고 딴거해야해서 비번 $말고 딴걸로 바꿈

[FastAPI, PostgreSQL] postgresql://와 postgresql+asyncpg:// 의 차이

the0 — Fri, 18 Oct 2024 17:06:52 +0900

글을 작성하게 된 이유:

FastAPI 에서 Session 생성을 하기 위해 postgresql url 을 주입하는 도중에 여러 프로젝트의 소스코드마다

postgresql://로 시작하는 url도 있고 postgresql+asyncpg:// 로 시작하는 url도 있었는데 그 차이가 궁금했다.

그리고 이것 때문에 프로젝트 실행하는 과정에서 삽질을 하기도 했다.

두 URL은 주로 동기 방식과 비동기 방식의 데이터베이스 연결 및 쿼리 실행 방식에 차이점이 있다.

postgresql://

이 url은 psycopg2와 같은 동기식 드라이버를 사용해 PostgreSQL 에 연결한다.

이게 표준 연결 문자열이다. (당연해보이죠?)

이는 파이썬*의 일반적인 동기 실행 모델을 따르기 때문에, 데이터베이스 작업을 수행하는 동안 해당 작업이 완료될 때까지 프로그램의 실행이 블로킹(대기 상태)된다.

*참고로 파이썬은 동기 방식으로 동작하도록 설계된 언어이다. 물론 asyncio 등 라이브러리로 비동기 방식을 지원하긴하지만 일반적으로는 그러하다.

postgresql+asyncpg://

asyncpg라는 비동기 드라이버를 사용해 PostgreSQL 에 연결한다.

비동기 드라이버를 사용하므로, 데이터베이스 작업이 비동기적으로 실행된다.

즉, 데이터베이스 작업을 기다리는 동안 다른 작업을 수행할 수 있어 리소스를 보다 효율적으로 사용할 수 있다. 예를 들면 서버의 반응성과 처리량이 높아진다거나...

이 url은 FastAPI와 같은 비동기 프레임워크와 함께 사용할 때 효과적이며, 동시에 많은 연결과 요청을 처리해야하는 애플리케이션에 적합하다

FastAPI가 비동기 프레임워크라고요?!

네. 그렇다고 합니다...

FastAPI는 uvicorn과 함께 비동기적인 형태로 동작합니다.. 더보기(나중에 더 알아보자는 뜻~^^)

[Docker] 원격에서 다른 원격의 외부 엔드포인트 호출 안됨

the0 — Wed, 2 Oct 2024 17:57:30 +0900

상황:

원격 VM A, B 가 있다.

A에 도커로 띄운 Spring Boot a1 이 B 서버의 엔드포인트로 API를 호출해야 함.

Docker 컨테이너로 실행시킨 스프링 부트는 잘 돌아가나 A ->B 호출만 안되는 상황

스프링 컨테이너를 실행한 명령어

docker run -d \
  --name my-backend \
  -p 8080:8080 \
  my-backend

해결 방법:

다음과 같이 `--network host` 옵션을 추가한다.

docker run -d \
  --name my-backend \
  -p 8080:8080 \
  --network host \
  my-backend

혹은 방화벽이나 보안 그룹 설정의 문제일 수도 있다.

만약 호스트의 방화벽 설정이 docker0 인터페이스를 통한 통신을 제한하고 있다면 외부 통신에 문제를 일으킬 수 있다.

그런 경우에는 아래의 블로그를 참고해보자.

Docker 컨테이너에서 외부 인터넷 접속이 되지 않을때

호스트에서는 인터넷 접속이 원활하게 되나 컨테이너 내부에서는 인터넷이 되지 않는 경우가 있다. 많은 블로그들에서는 docker run 실행시 --network=host 옵션을 추가해서 기본 bridge가 아닌 host로 만

albear.app

나는 회사 서버 방화벽 괜히 건드리기 무서워서 안했다..^^

이전 사람들이 안한 이유가 있지 않을까며 ^^..

그게 뭔데

호스트 네트워크를 사용하면 마치 호스트 내에서 애플리케이션을 실행한 것과 같아져 별도의 포드포워딩 없이 호스트의 네트워크를 사용하게 된다.

(같은말 반복) 네트워크를 호스트 모드로 실행하면 새로운 내부 IP를 할당받을 필요 없이 곧바로 localhost를 통해 접속할 수 있게 된다.

호스트 네트워크를 직접 사용하기에 NAT(Network Address Translation) 과정이 필요 없어진다.

=> 그리고 어쩐지 docker ps를 했을 때 `0.0.0.0:8080 => 8080` 같은 표시도 사라진다!

하지만 외부로부터 공격 접근이 온다면 호스트의 네트워크까지 직접적으로 공격당할 수 있으므로 주의해야 한다.

더 궁금한건 docker network host/bridge 키워드로 검색하길

끝!

오프라인 상태에서 cURL 사용하기

the0 — Tue, 1 Oct 2024 14:13:04 +0900

오프라인 상태에서 cURL을 사용할 수 있을까?

1. 요청 대상이 동일 네트워크/서버

요청할 대상이 동일 네트워크나 서버에 있으면 인터넷 연결 여부와 상관없이 cURL 테스트가 가능하다.

> 왜?

서버나 다른 대상이 같은 로컬 네트워크 내에 있으면 데이터는 같은 네트워크를 통해 직접 전송된다.

이 경우, 내부 네트워크의 라우팅 기능이 데이터를 대상 서버로 직접 전달하기 때문에 외부 인터넷 연결이 필요하지 않다.

> 예를 들면?

같은 로컬 네트워크 내의 서버에 접근할 때, 요청은 인터넷을 통해 외부로 나갔다가 다시 들어오는 대신에 내부적으로만 라우팅되어 처리된다.

2. 요청 대상이 외부 서버

오프라인 상태에서 외부 서버로 요청을 보내는 것은 불가능하다.

외부 서버는 인터넷을 통해 접근할 수 있기 때문에

서버가 인터넷에 연결되지 않은 상태에서는 외부 서버에 요청을 보낼 수 없다.