트랜잭션 서비스 추상화

참조

• 토비의 스프링 vol.1 348p~400p

이전에 구현했던 레벨 관리 기능에서 의문이 있다.

만약 사용자 레벨 관리 작업을 수행하는 도중에 서버에 장애가 생겨서 작업을 완료할 수 없다면, 그때까지 변경된 사용자의 레벨은 그대로 두어야할까? 되돌려야할까?

→ 일부 사용자만 레벨이 오른다면 반발이 있을 수도 있으므로 되돌리는 방향으로 하기로 했다.

현재의 레벨 관리 기능은 총 4명의 사용자의 레벨을 업데이트 하려는데 두번째 사용자를 업데이트 한 뒤에 에러가 발생 한다면 두번째 사용자까지는 레벨이 업데이트 된 상태이다.

→ upgradeLevels() 메소드가 하나의 트랜잭션 안에서 동작하지 않았기 때문이다.

트랜잭션이란 더 이상 나눌 수 없는 단위 작업을 말한다.

즉 upgradeLevels() 메소드가 하나의 트랜잭션 안에서 동작한다면 2번째 사용자를 업데이트 한 뒤 에러가 발생한다면 2번째 사용자까지 업데이트한 작업은 취소된다.

이런 취소작업을 “트랜잭션 롤백”이라고 하고, 성공적으로 하나의 트랜잭션을 마치고 DB에 결과를 반영하는 것을 “트랜잭션 커밋”이라고 한다.

서비스에서의 트랜잭션 경계설정 → 트랜잭션 동기화

• 트랜잭션을 시작하기 위해 만든 커넥션 오브젝트를 특별한 저장소에 보관해두고 이후에 호출되는 DAO의 메소드에서는 저장된 커넥션을 가져다가 사용한다.

기술과 상관없는 트랜잭션 경계설정 코드 → 트랜잭션 서비스 추상화

• 어떤 트랜잭션 구현 클래스를 사용할지 UserService가 아는것은 DI원칙에 위배 → 컨테이너를 통해 외부에서 제공받게 하도록 변경
• 싱글톤으로 만들어져 여러곳에서 동시에 사용해도 괜찮은지 검토 필요
• 트랜잭션 서비스 추상화를 도입하고 DI를 통해 외부에서 제어하도록 만드니까 UserService는 온전히 사용자 관리 로직이 바뀔때만 수정하면됨. → 단일 책임 원칙
  

서비스추상화와 단일 책임 원칙

• 서비스추상화 서비스 추상화는 로우레벨의 트랜잭션 기술과 API의 변회에 상관없이 일관된 API를 가진 추상화 계층을 도입한다.
  

• 단일 책임 원칙 하나의 모듈은 한가지 책임을 가져야 한다. 즉, 하나의 모듈이 바뀌는 이유는 한 가지여야 한다. 장점: 어떤 변경이 필요할 때 수정 대상이 명확해진다. 기술이 바뀌면 기술 계층과의 연동을 담당하는 기술 추상화 계층의 설정만 바꿔주면 된다.