토비 스프링 읽다가 트랜잭션 관련 기록 - 1

요즘 느끼는 거지만 정말 기록만이 살길이다.
토비의 스프링 6장을 읽으며 1권에서 가장 중요한 부분은 AOP이며 6장이 제일 중요하다고 느꼈다.
물론 나는 지금 두번째 읽고 있지만 이제 슬슬 이해가 가는 느낌이다.

정리를 한번하고 다음에 한번 더 읽을 때, 이 글을 보여 수정을 해볼 생각이다.

일단 AOP 관련 용어에 대한 개념을 확실하게 가지고 가야한다.

• 타깃
타깃은 부가기능을 부여할 대상이다. 핵심기능을 담은 클래스일 수도 있지만 경우에 따라서는 다른 부가기능을 제공하는 프록시 오브젝트일 수도 있다.

• 어드바이스
어드바이스는 타깃에게 제공할 부가기능을 담은 모률이다. 어드바이스는 오브젝트 로 정의하기도 하지만 메소드 레벨에서 정의할 수도 있다. 어드바이스는 여러 가지 종류가 있다. Methodlnterceptor처럼 메소드 호출 과정 에 전반적으로 참여히는 것도 있지만 예외가 발생했을 때만 동작하는 어드바이스처 럼 메소드 호출 과정의 일부에서만 동작하는 어드바이스도 있다.

• 조인포인트
처음 소개핸 용어다. 조인 포인트 joinPoint란 어드바이스가 적용될 수 있는 위치를 말한다. 스프링의 프록시 AOP에서 조인 포인트는 메소드의 실행 단계뿐이다. 타깃 오브젝트가 구현한 인터페이스의 모든 메소드는 조인 포인트가 된다.

·포인트컷
포인트컷이란 어드바이스를 적용할 조인 포인트를 선별하는 작업 또는 그 기능을 정의한 모률을 말한다. 스프링 AOP의 조인 포인트는 메소드의 실행이므로 스프링의 포인트컷은 메소드를 선정하는 기능을 갖고 있다.

·프록시
프록시는 클라이언트와 타깃 사이에 투명하게 존재하면서 부가기능을 제공히는 오브젝트다. DI를 통해 타깃 대신 클라이언트에게 주입되며 클라이언트의 메소드 호출을 대신 받아서 타깃에 위임해주면서, 그 과정에서 부가기능을 부여한다. 스프링은 프록시를 이용해 AOP를 지원한다.

·어드바이저
어드바이저는 포인트컷과 어드바이스를 하나씩 갖고 있는 오브젝트다. 어드바이저는 어떤 부가기능(어드바이스)을 어디에(포인트컷) 전달할 것인가를 알고 있는 AOP의 가장 기본이 되는 모률이다. 스프링은 자동 프록시 생성기가 어드바이저를 AOP 작업의 정보로 활용한다. 어드바이저는 스프링 AOP에서만 사용되는 특별한 용어이고, 일반적인 AOP에서는 시용되지 않는다.

 

[포인트컷과 트랜잭션 속성의 적용 전략]

- 트랜잭션 포인트컷 표현식은 타입 패턴이나 빈 이름을 이용한다

쓰기 작업이 없는 단순한 조회 작업만 히는 메소드에도 모두 트랜잭션을 적용하는 게 좋다. 조회의 경우에는 읽기전용으로 트랜잭션 속성을 설정해두면 그만큼 성능의 향 상을 가져올 수 있다. 또， 복잡한 조회의 경우는 제한시간을 지정해줄 수도 있고， 격리 수준에 따라 조회도 반드시 트랜잭션 안에서 진행해야 할 필요가 발생하기도 한다.

따라서 트랜잭션용 포인트컷 표현식에는 메소드나 따라미터， 예외에 대한 패턴을 정 의하지 않는 게 바람직하다. 트랜잭션의 경계로 삼을 클래스들이 선정됐다면， 그 클래 스들이 모여 있는 패커지를 통째로 선택하거나 클래스 이름에서 일정한 패턴을 찾아서 표현식으로 만들면 된다. 관례적으로 비즈니스 로직 서비스를 담당히는 클래스 이름은 Service 또는 ServiceImpl이라고 끝나는 경우가 많은데 그런 경우라면 execution(* *.. *ServiceImpl .*( .. ))과 같이 포인트컷을 정의하면 된다. 기능하면 클래스보다는 인터페이스 타입을 기준으로 타입 패턴을 적용하는 것이 좋다. 인터페이스는 클래스에 비해 변경 빈도가 적고 일정한 패턴을 유지하기 쉽기 때문이다.

- 공통된 메소드 이름 규칙을 통해 최소한의 트랜잭션 어드바이스와 속성을 정의한다

아래와 같이 처음에는 기본 트랜잭션 속성 지정하고

<tx:advice id="transactionAdvice">
	<tx:attributes>
    		<tx:method name="*" />
	</tx:attributes>
</tx:attributes>

점점 추가하는 방식으로

<tx:advice id="transactionAdvice">
	<tx:attributes>
    		<tx:method name="get*" read-only="true"/>
    		<tx:method name="*" />
	</tx:attributes>
</tx:attributes>

 

 

- 프록시 방식 AOP는 같은 타깃 오브젝트 내의 메소드를 호출할 때는 적용 되지않는다 (주의사항!)
프록시 방식의 AOP에서는 프록시를 통한 부가 기능의 적용은 클라이언트로부터 호출이 일어날 때만 가능하다. 여기서 클라이언트는 인터페이스를 통해 타깃 오브젝트를 사용하는 다른 모든 오브젝트를 말한다. 타깃 오브젝트가 자기 자신의 메소드를 호출할 때는 프록시를 통한 부가기능의 적용이 일어나지 않는다. 프록시가 적용되는 방식을 생각해보면 왜 그런지 알 수 있을 것이다.

그림 6-23은 트랜잭션 프록시가 타깃에 적용되어 있는 경우의 메소드 호출 과정을 보여준다. de!ete()와 update( )는 모두 트랜잭션 적용 대상인 메소드다. 따라서 [1 ]과 [3]처럼 클라이언트로부터 메소드가 호출되면 트랜잭션 프록시를 통해 타깃 메소드로 호출이 전달되므로 트랜잭션 경계설정 부가기능이 부여될 것이다.

하지만 [3]의 경우는 다르다. 일단 타깃 오브젝트 내로 들어와서 타깃 오브젝트의 다른 메소드를 호출하는 경우에는 프록시를 거치지 않고 직접 타깃의 메소드가호출된다. 따라서 [1] 클라이언트를 통해 호출된 de!ete( ) 메소드에는 트랜잭션 속성이 적용되지만, [2]를 통해 update( ) 메소드가 호출될 때는 update() 메소드에 지정된 트랜잭션 속성이 전혀 반영되지 않는다.

만약 update( ) 메소드에 대해 트랜잭션 전파 속성을 REQUIRES_NEW라고 해놨더라도 같은 타깃 오브젝트에 있는 de!ete( ) 메소드를 통해 update()가 호출되면 트랜잭션 전파 속성이 적용되지 않으므로 REQUIRES_NEW는 무시되고 프록시의 de!ete() 메소드에서 시작한 트랜잭션에 단순하게 참여하게 될 뿐이다. 또는 트랜잭션이 아예 적용되지 않는 타깃의 다른 메소드에서 update()가 호출된다면 그때는 트랜잭션이 없는 채로 update() 메소드가 실행될 것이다.

이렇게 같은 타깃 오브젝트 안에서 메소드 호출이 일어나는 경우에는 프록시 AOP 를 통해 부여해준 부가기능이 적용되지 않는다는 점을 주의해야 한다. 따라서 같은 오브젝트 안에서의 호출은 새로운 트랜잭션 속성을 부여하지 못한다는 사실을 의식하고 개발할 펼요가 있다. 기껏해야 get으로 시작하는 메소드에 읽기전용 속성을 부여하고 REQUIRED 전파 속성을 사용히는 일반적인 경우에는 문제될 게 없다. 하지만 복잡한 트랜잭션 전파 속성을 적용히는 경우라면 기대와 다르게 트랜잭션 속성이 무시될 가능성 이 있으니 주의해야한다.