상황과 서비스 인터페이스 및 트랜잭션 프록시외관, 봄
사용자가 Facade 패턴 하나의 다른를 사용하기 때문에, 다양한 서비스 객체 (POJO를 또는 세션 콩)와 직접 상호 작용하지 않을 것이라는 높은 가능성이있다 서비스는 한 묶음으로 수집됩니다.
@Transactional 주석은 Facade의 메소드와 달리 단일 서비스의 메소드 레벨에 적용됩니다.
서비스에 인터페이스가없는 경우 Spring은 좋은 트랜잭션 프록시를 사용할 수 없으므로 다양한 문제가 발생합니다.
질문
원하는 연습은 무엇입니까? 좋은 프록시 위해서
@Transactional 특수 이동 (내부적으로도 서비스를 이용함으로써 트랜잭션을 위해 외관을 통과해야한다).현장 경험은 무엇입니까? 나는 또한 넓은 관점에서 고려해야 할 사항에 열려 있습니다.
서비스에 인터페이스가 없다면, Spring은 여전히 CGLIB proxies을 사용하여 트랜잭션 측면을 적용 할 수 있습니다. 대부분의 경우 잘 작동합니다. 실제 문제는 서비스에 인터페이스가 있지만 트랜잭션 방식이 이러한 인터페이스의 일부가 아닌 경우에 발생합니다.
그러나 Facade 인터페이스는 명확한 트랜잭션 경계를 정의하므로 Facade 메서드에 @Transactional을 적용하는 것이 더 안전한 솔루션이 될 수 있습니다. 이 경우 Facade를 사용하여 서비스를 사용하는 것에 대해 걱정할 경우 @Transactional을 Facade 메소드뿐 아니라 서비스에도 적용 할 수 있습니다. 이 경우 Facade 메소드를 호출 할 때 생성 된 트랜잭션은 서비스 메소드에 대해 propagated입니다.
트랜잭션 경계를 설정하는 유일한 기준은 기술적 인 문제가 아닌 비즈니스 논리 조건이어야합니다. 서비스 메소드가 원자 적 조작이어야한다면 트랜잭션을 관리하십시오. 당신의 정면이 둘 이상의 서비스 콜을 결합 할 수 있고 함께 "모두 또는 아무것도 실행하지 말아야한다"는 것은 트랜잭션이 외면에 놓여 져야 함을 의미합니다. 언급 된 axtavt와 같이, cglib 프록시는 인터페이스가없는 클래스를 프록시하는 데 사용될 수 있습니다.
또한 마크 리차드로이 시리즈를 추천 : http://www.ibm.com/developerworks/views/java/libraryview.jsp?search_by=transaction+strategies :
+1 기준 – ron
감사합니다. 결국 서비스는 외관없이 사용되지 않습니다. @Transactional missing 인터페이스에 대한 언급은 문제를 야기 할 수 있다는 점도 좋은 지적이다. – ron