[스프링 DB 1편] #4. 스프링과 문제해결(1) - 트랜잭션

[Pracrobo]

대표적인 애플리케이션 구조

프레젠테이션 계층

• UI와 관련된 처리를 담당한다
• 웹 요청과 응답
• 사용자 요청을 검증한다
• 주 사용 기술: 서블릿과 HTTP 같은 웹 기술, 스프링 MVC 를 많이 사용한다.

서비스 계층

• 비즈니스 로직을 담당
• 주 사용기술 : 순수 자바 코드로 작성

데이터 접근 기술

• 실제 데이터베이스에 접근하는 코드
• 주 사용기술 : JDBC, JPA, File, Redis, Mongo

서비스 계층이 핵심 비즈니스 로직이 들어있어 특정 기술에 종속적이지 않게 개발해야 한다.

서비스 계층을 최대한 순수하게 유지하기 위한 목적이 크다.

MemberServiceV1

package hello.jdbc.service;
 
import java.sql.SQLException;
@RequiredArgsConstructor
public class MemberServiceV1 {
private final MemberRepositoryV1 memberRepository;
public void accountTransfer(String fromId, String toId, int money) throws 
SQLException {
Member fromMember = memberRepository.findById(fromId);
Member toMember = memberRepository.findById(toId);
      memberRepository.update(fromId, fromMember.getMoney() - money);
      memberRepository.update(toId, toMember.getMoney() + money);
  }
}

• MemberServiceV1은 특정 기술에 종속적이지 않고 순수한 비즈니스 로직만 존재한다.
• 코드가 깔끔하고 유지보수하기 쉽다.
• 향후 비즈니스 로직의 변경이 필요하면 이 부분을 변경하면 된다.

지금은 참고만 할 문제들

• SQLException이라는 JDBC 기술에 의존한다는점
• memberRepository 에서 올라오는 예외이기 때문에 MemberRepository 인터페이스를 도입하면 향후 MemberService의 코드의 변경없이 다른 구현 기술로 손쉽게 변경할 수 있다.

MemberServiceV2

package hello.jdbc.service;
 import javax.sql.DataSource;
 import java.sql.Connection;
 import java.sql.SQLException;
 @Slf4j
@RequiredArgsConstructor
public class MemberServiceV2 {

	private final DataSource dataSource;
	private final MemberRepositoryV2 memberRepository;
	public void accountTransfer(String fromId, String toId, int money) throws 
	SQLException {
		Connection con = dataSource.getConnection();
		try {
        con.setAutoCommit(false); //트랜잭션 시작
				//비즈니스 로직
				bizLogic(con, fromId, toId, money);
        con.commit(); //성공시 커밋
      } 
		catch (Exception e) {
        con.rollback(); //실패시 롤백
				throw new IllegalStateException(e);
	    } finally {
					release(con);
			}
	}
				
	private void bizLogic(Connection con, String fromId, String toId, int money) 
throws SQLException {
			Member fromMember = memberRepository.findById(con, fromId);
			Member toMember = memberRepository.findById(con, toId);
      memberRepository.update(con, fromId, fromMember.getMoney() - money);
      memberRepository.update(con, toId, toMember.getMoney() + money);
  }
}

• 트랜잭션은 비즈니스 로직이 있는 서비스 계층에서 시작하는 것이 좋다.
• 그런데 문제는 트랜잭션을 사용하기 위해서 javax.sql.DataSource, java.sql.Connection, java.sql.SQLException 같은 JDBC 기술에 의존해야 한다는 점이다.
• 트랜잭션을 사용하기 위해 JDBC 기술에 의존한다. 결과적으로 비즈니스 로직보다 JDBC를 사용해서 트랜잭션을 처리하는 코드가 더 많다.
• 향후 JDBC에서 JPA 같은 다른 기술로 바꾸어 사용하게 되면 서비스 코드도 모두 함께 변경해야 한다.( JPA는 트랜잭션을 사용하는 코드가 JDBC와 다르다.)
• 핵심 비즈니스 로직과 JDBC 기술이 섞여 있어 유지보수하기 어렵다.

문제 정리

3가지가 있다.

• 트랜잭션 문제
• 예외 누수 문제
• JDBC 반복 문제

1. 트랜잭션 문제

• JDBC 구현 기술이 서비스 계층에 누수되는 문제
  • 트랜잭션을 적용하기 위해 JDBC 구현 기술이 서비스 계층에 누수되었다.
  • 서비스 계층은 순수해야한다.
    • 그래서 데이터 접근 계층에 JDBC 코드를 다 몰아둔다.
    • 물론 데이터 접근 계층의 구현기술이 변경될 수도 있으니 데이터 접근 계층은 인터페이스를 제공하는 것이 좋다.
  • 서비스 계층은 특정 기술에 종속되지 않아야 한다. 지금까지 그렇게 노력해서 데이터 접근 계층으로 JDBC 관련 코드를 모았는데 트랜잭션을 적용하면서 서비스 계층에도 JDBC 구현 기술의 누수가 발생했다.
• 트랜잭션 동기화 문제
  • 같은 트랜잭션을 유지하기 위해 커넥션을 파라미터로 넘겨야한다.
  • 이때 파생되는 문제들: 똑같은 기능도 트랜잭션 기능과 트랜잭션을 유지하지 않아도 되는 기능으로 분리해야한다.
• 트랜잭션 적용 반복 문제
  • 트랜잭션 적용 코드를 보면 반복이 많다. try, catch, finally

2. 예외 누수

• 데이터 접근 계층의 JDBC 구현 기술 예외가 서비스 계층으로 전파된다.
• SQLException은 체크 예외이기 때문에 데이터 접근 계층을 호출한 서비스 계층에서 해당 예외를 잡아서 처리하거나 명시적으로 throwss 를 통해 다시 밖으로 던져야한다.
• SQLException은 JDBC 전용 기술이다. 향후 JPA나 다른 데이터 접근 기술을 사용하면 그에 맞는 다른 예외로 변경해야하고 결국 서비스 코드도 수정해야 한다.

3. JDBC 반복 문제

• 지금까지 작성한 MemberRepository 코드는 순수한 JDBC를 사용했다.
• 이 코드들은 유사한 코드의 반복이 너무 많다.
  • try, catch, finally
  • 커넥션을 열고 PreparedStatement를 사용하고 결과를 매핑하고 실행하고 커넥션과 리소스를 정리한다.