Synchronizing Resources with Transactions

서로 다른 transaction manager를 생성하는 방법과 transaction에 동기화되어야 하는 관련 resource(예를 들어 JDBC DataSource에 대한 DataSourceTransactionManager, Hibernate SessionFactory에 대한 HibernateTransactionManager 등)에 어떻게 연결되는지는 이제 명확해야 합니다. 이 섹션에서는 애플리케이션 code가 (직접적으로 또는 JDBC, Hibernate, JPA와 같은 persistence API를 사용함으로써 간접적으로) 이러한 resource가 올바르게 생성, 재사용 및 정리되도록 보장하는 방법을 설명합니다.

또한 이 섹션에서는 관련 TransactionManager를 통해 transaction synchronization이 (선택적으로) 어떻게 트리거되는지도 논의합니다.

High-level Synchronization Approach

선호되는 접근 방식은 Spring의 가장 상위 수준 template 기반 persistence integration API를 사용하거나, native resource factory를 관리하기 위해 transaction-aware factory bean 또는 proxy와 함께 native ORM API를 사용하는 것입니다. 이러한 transaction-aware solution은 내부적으로 resource 생성 및 재사용, 정리, resource의 선택적 transaction synchronization, 예외 매핑을 처리합니다.

따라서 사용자 data access code는 이러한 작업을 처리할 필요가 없으며, 순수하게 boilerplate가 아닌 persistence logic에만 집중할 수 있습니다. 일반적으로 native ORM API를 사용하거나 JdbcTemplate을 사용하여 JDBC access에 대해 template approach를 취합니다. 이러한 solution은 이 reference documentation의 이후 섹션에서 자세히 설명됩니다.

Low-level Synchronization Approach

DataSourceUtils(JDBC용), EntityManagerFactoryUtils(JPA용), SessionFactoryUtils(Hibernate용) 등과 같은 class는 더 낮은 수준에 존재합니다. 애플리케이션 code가 native persistence API의 resource type을 직접 다루기를 원할 때, 이러한 class를 사용하여 적절한 Spring Framework에서 관리되는 instance를 얻고, transaction이 (선택적으로) 동기화되며, 그 과정에서 발생하는 예외가 일관된 API에 적절히 매핑되도록 합니다.

예를 들어 JDBC의 경우, 전통적인 JDBC 방식으로 DataSource의 getConnection() 메서드를 호출하는 대신, 다음과 같이 Spring의 org.springframework.jdbc.datasource.DataSourceUtils class를 사용할 수 있습니다:

1Connection conn = DataSourceUtils.getConnection(dataSource);

기존 transaction에 이미 connection이 동기화(연결)되어 있으면 해당 instance가 반환됩니다. 그렇지 않으면 메서드 호출이 새로운 connection 생성 트리거가 되며, 이 connection은 (선택적으로) 기존 transaction에 동기화되고 동일한 transaction 내에서 이후 재사용을 위해 사용 가능하게 됩니다. 앞에서 언급했듯이, 모든 SQLException은 Spring Framework의 CannotGetJdbcConnectionException으로 wrapping되며, 이는 Spring Framework의 unchecked DataAccessException type 계층 중 하나입니다.

이 접근 방식은 SQLException에서 쉽게 얻을 수 있는 것보다 더 많은 정보를 제공하고, database 간은 물론 서로 다른 persistence technology 간의 이식성을 보장합니다. 이 접근 방식은 Spring transaction management 없이도 (transaction synchronization은 선택 사항) 작동하므로, transaction management를 위해 Spring을 사용하든 사용하지 않든 사용할 수 있습니다.

물론 Spring의 JDBC support, JPA support 또는 Hibernate support를 한 번 사용해 보면, 일반적으로 DataSourceUtils나 다른 helper class를 사용하고 싶지 않게 됩니다. 왜냐하면 관련 API를 직접 사용하는 것보다 Spring abstraction을 통해 작업하는 것이 훨씬 더 만족스럽기 때문입니다. 예를 들어 Spring JdbcTemplate 또는 jdbc.object 패키지를 사용하여 JDBC 사용을 단순화하는 경우, 올바른 connection retrieval이 내부에서 처리되므로 특별한 code를 작성할 필요가 없습니다.

TransactionAwareDataSourceProxy

가장 낮은 수준에는 TransactionAwareDataSourceProxy class가 존재합니다. 이는 target DataSource에 대한 proxy로서, target DataSource를 wrapping하여 Spring에서 관리하는 transaction에 대한 인식을 추가합니다. 이러한 점에서, 이는 Jakarta EE server에서 제공하는 transactional JNDI DataSource와 유사합니다.

기존 code를 호출해야 하고 표준 JDBC DataSource 인터페이스 implementation을 전달해야 하는 경우를 제외하고, 이 class를 사용해야 하거나 사용하고 싶어 하는 경우는 거의 없어야 합니다. 그 경우, 이 code가 사용 가능하지만 Spring에서 관리하는 transaction에 참여하고 있을 가능성이 있습니다. 앞에서 언급한 상위 수준 abstraction을 사용하여 새로운 code를 작성할 수 있습니다.