JPA / Persistence Context / Transactional

Goal

• JDBC
• Spring Data JPA
• Persistence Context

---

JDBC?

Spring JDBC 란 Spring Framework 와 DB 간 통신을 위한 인터페이스로 개발자가 사용하고자 하는 벤더사의 제품에 관계없이 DB 접근이 가능하게 해준다. 하지만 JDBC 는 Persistence Layer 와 긴밀한 관계를 맺기 때문에 개발자가 직접 Connection 설정하거나 Statement 를 이용해 원하는 작업을 수행 후 Statement 를 직접 닫아줘야 하는 등의 문제점이 야기될 수 있으며, 중복 코드의 재생산으로 인해 유지보수의 난이도가 상승하게 된다.

 

JDBC Architecture (출처 : Microsoft Tech Community)

---

Spring Data JPA

ORM(Object Relation Mapper) 중 하나로, 관계형 데이터베이스와 Java 의 객체 지향 프로그래밍을 연결해주는 징검다리 역할을 하는 인터페이스이다. JPA 와 같은 ORM 은 IoC(제어의 역전) 을 통해 JDBC 에서 발생하는 Connection 이나 Statement 관리 등의 문제점을 해결하여 개발자가 직접 Query 작성을 줄이고 오롯이 비즈니스 로직에만 집중할 수 있다는 장점이 있다.
이러한 JPA 는 Hibernate 라는 구현체를 통해 구현되어 있으며, 이를 통해 영속성 컨텍스트(Persistence Context)에 속한 Entity 를 손쉽게 관리 할 수 있다.

Repository / Method Define

@Repository
interface ProductOptionRepository :
    JpaRepository<ProductOption, String>,
    QuerydslPredicateExecutor<ProductOption> {

    fun findProductOptionsByProductIdIn(productIds: List<String>): List<ProductOption>
}

JPA 에 의해 만들어진 Query

select p1_0.id,
       p1_0.app_price,
       p1_0.name,
       p1_0.product_id,
       p1_0.registration_date,
       p1_0.search_keyword,
       p1_0.shelf_life,
       p1_0.status,
       p1_0.web_price
from product_option p1_0
where p1_0.product_id in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)

---

EntityManager / EntityManagerFactory

JPA 의 의존성을 추가하게 되면 EntityManager 에 의해 영속성 컨텍스트가 생성되고, Entity 로 등록된 객체들은 영속성 컨텍스트에 의해 생명주기가 관리되며, EntityManager 는 애플리케이션에 의해 관리된다.
이 때 EntityManagerFactory 를 통해 EntityManager 가 생성되는데, EntityManagerFactory 는 Thread-safe, EntityManager 는 Thread-safe 하지 못하다. 때문에 EntityManager 는 스레드 당 하나만 존재하게 된다.
또한 EntityManager 는 Transaction 수행 시, 내부적으로 Connection Pool 에서 하나의 Connection 을 이용하고 Transaction 이 종료되면 Connection 을 다시 Connection Pool 로 반환한다.

🔍 EntityManagerFactory 는 왜 생성 비용이 비쌀까?
> 추측하건데 아마 JDBC 와 비슷하게 DB 와 연결하기 위한 과정에 많은 리소스를 사용하기 때문인걸까? 스터디 때 질문 해야겠다.

// 애플리케이션 실행 시, EntityFactoryManager 초기화
public abstract class AbstractEntityManagerFactoryBean implements
		FactoryBean<EntityManagerFactory>, BeanClassLoaderAware, BeanFactoryAware, BeanNameAware,
		InitializingBean, DisposableBean, EntityManagerFactoryInfo, PersistenceExceptionTranslator, Serializable {
        	private EntityManagerFactory buildNativeEntityManagerFactory() {
                EntityManagerFactory emf;
                try {
                    emf = createNativeEntityManagerFactory();
                }
                catch (PersistenceException ex) {
                    if (ex.getClass() == PersistenceException.class) {
                        // Plain PersistenceException wrapper for underlying exception?
                        // Make sure the nested exception message is properly exposed,
                        // along the lines of Spring's NestedRuntimeException.getMessage()
                        Throwable cause = ex.getCause();
                        if (cause != null) {
                            String message = ex.getMessage();
                            String causeString = cause.toString();
                            if (!message.endsWith(causeString)) {
                                ex = new PersistenceException(message + "; nested exception is " + causeString, cause);
                            }
                        }
                    }
                    if (logger.isErrorEnabled()) {
                        logger.error("Failed to initialize JPA EntityManagerFactory: " + ex.getMessage());
                    }
                    throw ex;
                }

                JpaVendorAdapter jpaVendorAdapter = getJpaVendorAdapter();
                if (jpaVendorAdapter != null) {
                    jpaVendorAdapter.postProcessEntityManagerFactory(emf);
                }

                if (logger.isInfoEnabled()) {
                    logger.info("Initialized JPA EntityManagerFactory for persistence unit '" + getPersistenceUnitName() + "'");
                }
                return emf;
            }
        }

---

Persistence Context

EntityManager 는 Transaction 작업 수행 시 영속성 컨텍스트에 Entity 를 담고, 해당 Entity 의 생명주기를 관리한다. 그렇다면 여기서 영속성 컨텍스트(Persistence Context) 는 무엇을 의미할까?

영속성 컨텍스트란 '영구적으로 데이터를 저장하는 환경' 이라는 뜻으로, 애플리케이션과 DB 사이의 1차 캐시 같은 의미를 가진다.
단순히 캐시와 같이 작동으로 끝나는 것이 아닌 컨텍스트에 등록된 Entity 인스턴스는 변경 감지, 동일성 보장, 쓰기 지연 등 여러 편의 기능을 제공한다. 또한, 해당 Transaction 에서 수행되어야 할 모든 Query 가 commit 된 뒤에 Entity 의 상태가 변경된다. (RDBMS 의 Rollback 과 비슷하다.)
하지만 영속성 컨텍스트에 포함되지 않는 엔티티는 (Transaction 전파 범위를 벗어난 경우) 조회 시 예외가 발생한다. 

영속성 컨텍스트에  관리되는 Entity Instance

@Service
class ProductService(
    private val productOptionRepository: ProductOptionRepository
) {
    @Transactional
    fun updateProductOption(product: Product, productOption: ProductOption) {
        val productOption = productOptionRepository.findById("10")
            .orElseThrow { IllegalArgumentException("제품 옵션이 존재하지 않습니다.") }

        val product = productOption.product

		// EntityManager 에 의해 Dirty Checking
        // 변경이 확인되면 변경 내용이 DB 에 반영된다.
        productOption.name = "256GB"
        product?.name = "[신제품] 아이폰15"
    }
}

Transaction 전파 범위를 넘어가는 경우 예외 발생

@Service
class ProductService(
    private val productOptionRepository: ProductOptionRepository
) {
	@Transactional
	fun mapToDto(productOption: ProductOption): ProductRespDto {
        val productOption = productOptionRepository.findById("10")
            .orElseThrow { IllegalArgumentException("제품 옵션을 찾을 수 없습니다.") }
        
        return ProductRespDto(productOption)
    }
}

class ProductRespDto(
	productOption: ProductOption
) {
	// Transaction 의 전파 범위를 벗어나면 Join 하고 있는 데이터 접근 시 예외 발생
	val productName: String = productOption.product.name
    val productOptionName: String = productOption.name
}

영속성 컨텍스트의 이점

• 1차 캐시
  • 영속성 컨텍스트에서 관리되고 있는 Entity 인스턴스를 현재 Transaction 에서 다시 조회할 때, 영속성 컨텍스트에서 해당 인스턴스를 조회하도록 한다. 만약 영속성 컨텍스트에 찾고자 하는 인스턴스가 존재하지 않는다면 DB 를 통해 조회하여 영속성 컨텍스트에 추가하고, 생명주기를 관리한다.
• 동일성 보장

val person1 = em.find(Person::class.java, 1L)
val person2 = em.find(Person::class.java, 1L)

// 영속성 컨텍스트에 의해 관리되는 Entity 인스턴스는 동일한 트랜젹션 내에서 조회 할 경우 객체의 동일성을 보장한다.
println(person1 == person2)

• 쓰기 지연
  • EntityManager 는 트랜잭션을 Commit 하기 전에 내부의 쿼리 저장소에 해당 트랜잭션에서 호출된 Insert Query 를 모아두고, Commit 이 되는 시점에 저장소에 저장한 Insert Query 를 DB 로 전송하는데 이를 쓰기 지연이라고 한다.
• 변경 감지(Dirty Check)
  • 영속성 컨텍스트에 관리되는 Entity 인스턴스들의 변경을 감지하고, 별도로 Update Query 를 날리지 않아도 DB 로 전송된다.
    • flush() 발생
    • 1차 캐시 데이터와 Entity 의 스냅샷을 비교
    • Update Query 생성
    • flush(), 영속성 컨텍스트에 있는 값을 데이터베이스로 전송
    • commit()

 

---

Entity Lifecycle

영속성 컨텍스트에 의해 관리되는 Entity 는 다음과 같은 영속성 생명주기를 거치게 된다.

- 비영속 객체(new / transient) : 영속성 컨텍스트와 관계가 없는 상태
- 영속 객체(managed) : 영속성 컨텍스트에 의해 관리되는 Entity 인스턴스로 해당 인스턴스는 Dirty Check 에 의해 자동으로 데이터베이스에 전파된다.
- 준영속 객체(detached) : 영속성 컨텍스트에 관리되다가 분리된 인스턴스로 더이상 추적되지 않는다.
- 삭제 객체(removed) : 세션에 의해 delete() 메소드가 호출되면 삭제된 인스턴스로 인지한다. 하지만 Entity 인스턴스는 EntityManager 의 작업 단위가 종료될 때까지 영속석 컨텍스트에 존재한다.

---

Transaction

Transaction 이란 하나의 작업 단위라는 의미로 여러 Query 를 하나의 Transaction 으로 묶어 Commit 하면 DB 에 반영된다. 만약 Transaction 수행 도중 문제가 발생하면 Rollback 하여 데이터의 원자성을 유지하도록 한다.
이러한 Transaction 의 특성은 다음과 같다.

- 원자성 : Transaction 내의 질의는 모두 성공하거나 모두 실패해야 한다.
- 일관성 : 작업의 처리 결과가 항상 일관성이유지되어야 한다. (무결성 제약조건 등)
- 독립성 : 여러 Transaction 이 수행 되더라도 각각의 Transaction 은 서로 영향을 미치지 않아야 한다.
- 지속성 : Transaction 이 성공적으로 수행을 마치면 변경된 데이터가 DB 영구적으로 보존되어야 한다.

@Transactional

JPA 는 Transaction 의 원자성, 일관성, 독립성, 지속성을 유지하기 위해 @Transactional 어노테이션을 지원한다.
해당 어노테이션은 Transaction 수행 시 전파 유형, 격리 수준, read-only, Rollback 규칙 등을 설정 할 수 있으며, Class 혹은 Method 에 지정하여 사용 할 수 있다.

@Transactional
class ProductService {

	@Transactional(readonly = true)
	fun findProduct(id: String): Product {
    	...
    }
}

전파 유형

• REQUIRED
  • @Transactional 의 기본 전파 유형 설정이다. 때문에 @Transactional 어노테이션 사용 시, 새로운 Transaction 을 생성한다.
• SUPPORTS
  • 현재 활성화된 Transaction 이 존재하는지 확인하고, 존재하는 경우 기존 Transction 을, 존재하지 않는 경우 Transaction 을 사용하지 않도록 한다.
• MANDATORY
  • 활성화된 Transaction 이 존재해야 하며, 기존 Transaction 을 사용한다. 만약 활성 Transaction 이 존재하지 않는 경우 예외를 발생한다.

if (isExistingTransaction()) {
    if (isValidateExistingTransaction()) {
        validateExisitingAndThrowExceptionIfNotValid();
    }
    return existing;
}
throw IllegalTransactionStateException;

• REQUIRES_NEW
  • 현재 Transaction 이 존재하는 경우 기존 Transaction 을 종료하고, 진행 중인 비즈니스 로직에 새로운 Transaction 을 생성하여 수행하도록 한다.
• NOT_SUPPOERTED
  
  • 현재 Transaction 이 존재하는 경우 기존 Transaction 을 종료하고, 진행 중인 비즈니스 로직은 Transaction 없이 수행하도록 한다.
• NEVER
  • 해당 전파 유형으로 설정하는 경우, 클래스 및 메소드 호출 시 활성된 Transaction 이 존재하는 경우 예외를 발생한다.

if (isExistingTransaction()) {
    throw IllegalTransactionStateException;
}
return emptyTransaction;

• NESTED
  • 현재 Transaction 이 존재하는 경우 부모 Transaction 의 Commit / Rollback 에 영향을 받고, 자신의 Commit / Rollback 에 대해서는 영향을 받지 않는다. 즉, 주도권이 부모 Transaction 에 있다. 

격리 수준

격리 수준은 ACID 특성 중 하나로, 동시 Transaction 를 어떻게 처리할지에 대해 설정한다.
이러한 격리 수준은 다음의 영향력을 가진다.

- DIrty Read : 동시 Transaction 의 Commit 되지 않은 변경 사항을 조회한다.
- Nonrepeatable Read : 동시 Transaction 이 동일한 행을 업데이트 및 커밋을 하는 경우 행을 읽을 때 다른 값을 가져온다.
- Phantom Read : 다른 Transaction 의 범위 중 일부 데이터를 추가하거나 제거한다. 혹은 Commit 하는 경우 범위에 대한 Query 를 다시 실행한 후 다른 데이터를 가져온다.

• DEFAULT
  • @Transactional 의 기본 격리 수준이다. 이는 RDBMS 의 기본 격리 수준이다.
• READ_UNCOMMITED
  • 가장 낮은 격리 수준으로 동시 엑세스를 허용한다. 때문에 동시성 부작용이 모두 발생하는데, 해당 격리 수준으로 설정되는 경우 동시 Transaction 수행 시, 다른 Transaction 에서 Commit 되지 않은 데이터를 읽어 동시성 문제를 발생시킨다. 그래서 실행할 때 마다 다른 결과를 얻을 수 있다는 점을 유의해야 한다.
• READ_COMMITED
  • 동시 Transaction 수행 시 다른 Transaction 이 Commit 된 이후 변경된 데이터를 조회하도록 하는 격리 수준으로 Dirty Read 를 방지한다. 다만 Nonreapeatable Read / Phantom Read 는 여전히 방지하지 못해 동시성 문제가 발생 할 수 있다.
• REPEATABLE_READ
  • Dirty Read 및 Nonreapeatable Read 를 방지하는 격리 수준이다. 즉, 동시 Transaction 수행 중 Commit 되지 않은 내용은 영향을 받지 않는다. 또한, 업데이트 손실을 방지하기 위해 동시 Transaction 수행 시 동시 엑세스를 허용하지 않는다.
• SERIALIZABLE
  • 모든 동시성 문제를 해결할 수 있지만 Transaction 을 순차적으로 실행하기 때문에 엑세스 속도가 가장 낮다.