트랜잭션 추상화의 필요성.

트랜잭션 추상화는 왜 필요할까?
이걸 이해하기 위해선 왜 등장 했는지 알아야 한다.
데이터베이스 구현 기술에 따른 트랜잭션 사용 방법은 다 다르다..
JDBC는 con.setAutoCommit(false)로 트랜잭션을 시작해야 하고
JPA는 transaction.begin()으로 트랜잭션을 시작해야 한다.

상상해보자.. 만약 나의 코드는 JDBC를 사용하여 con.setAutoCommit(false)라는 코드가 1000개가 넘는 서비스에서 사용되고 있다..
이 상황에서 JPA로 넘어가려고 한다면..? 기존 con.setAutoCommit(false) 코드들을 transaction.begin()로 변경해 줘야 하고 뿐만 아니라 close하는 코드도 모두~~ 변경 해 줘야 한다.

이를 해결하기 위해 트랜잭션 추상화 개념을 도입하게 된 것이다.
의존성을 낮춰 유동성있는 트랜잭션을 사용할 수 있다.

서비스는 특정 트랜잭션 기술에 직접 의존하는 것이 아니라, TxManager 라는 추상화된 인터페이스에 의존한다.
원하는 구현체를 DI를 통해서 주입하면 된다.
예를 들어서 JDBC 트랜잭션 기능이 필요하면 JdbcTxManager 를 서비스에 주입하고, JPA 트랜잭션 기능으로 변경해야 하면 JpaTxManager 를 주입하면 된다.
클라이언트인 서비스는 인터페이스에 의존하고 DI를 사용한 덕분에 OCP 원칙을 지키게 되었다.
이제 트랜잭션을 사용하는 서비스 코드를 전혀 변경하지 않고, 트랜잭션 기술을 마음껏 변경할 수 있다.

스프링의 트랜잭션 추상화.

스프링은 이미 이런 고민을 다 해두었다.
우리는 스프링이 제공하는 트랜잭션 추상화 기술을 사용하면 된다.
심지어 데이터 접근 기술에 따른 트랜잭션 구현체도 대부분 만들어두어서 가져다 사용하기만 하면 된다.

스프링 트랜잭션 추상화의 핵심은 PlatformTransactionManager 인터페이스이다.
getTransaction() : 트랜잭션을 시작한다. 기존에 이미 진행중인 트랜잭션이 있는 경우 해당 트랜잭션에 참여할 수 있다.
commit() : 트랜잭션을 커밋한다.
rollback() : 트랜잭션을 롤백한다.

스프링은 보면 볼 수록 다양한 방향으로 개발 할 수 있도록 설계되어 있는 것 같다.
나도 앞으로 코드를 짤 때 이런식으로 다양한 가능성을 보고 의존성을 낮추는 설계를 하도록 노력해야겠다!!