스프링 데이터 JPA는

아래

컨트롤러의 흐름입니다 @Transactional 매니저.

나는 jpa:repositories에 지정된 txn 관리자가 고려되며 서비스 계층에서 @Transactional을 지정하는 데 영향이 없다고 생각됩니다. 예 : 서비스 계층 @Transactional을 사용자 지정 txn 관리자에 매핑 할 수 있습니다. 여기서 서비스가 호출하는 리포지토리에 다른 txn 관리자가있을 수 있습니다. 이 경우 문제가되지 않습니까?

누가 우리가 jpa 저장소를 사용할 때 @Transactional을 서비스 계층에 넣어야하는지 명확히 할 수 있습니까? 봄 데이터 참조의

출처

2013-10-31 lives

트랜잭션은 DAO 계층에서 구분되어서는 안됩니다. 단일 작업 단위는 일반적으로 여러 DAO를 사용하고 단일 트랜잭션 서비스 방법으로 조정됩니다. 왜 오직 하나만 원하기 때문에 두 개의 다른 트랜잭션 관리자를 정의하겠습니까? –

예 ... 여러 개의 데이터베이스 호출을 할 때 하나의 트랜잭션이 여러 개가 아니기를 원합니다. 따라서 서비스 수준에서 시작된 트랜잭션이 필요합니다. –

동의 함. 현재 구현에는 디자인 문제가 있습니다. 이 서비스는 두 개의 서로 다른 스키마 (이것은 JTA가 아니라 순수한 선택 쿼리)에 연결하는 재개발을 호출합니다. 이것이 jpa 저장소가 다른 엔티티 관리자 팩토리 및 다른 txn 관리자로 구성되는 이유입니다. – lives

페이지의 섹션 2.3 : 저장소에

http://docs.spring.io/spring-data/jpa/docs/1.0.0.M1/reference/html/#transactions

CRUD 방법은 기본적으로 트랜잭션입니다. 이러한 트랜잭션은 필요에 따라 구성 할 수 있지만 위의 설명에서 제안하는대로 일반적으로 트랜잭션은 서비스 계층 및 그 경우에 지정됩니다.

리포지토리의 트랜잭션 구성은 무시됩니다 외부 트랜잭션 구성이 실제 하나를 결정하므로 이 사용됩니다.

귀하의 질문에 대한 답변으로, 스프링 데이터 트랜잭션 관리와 상관없이 서비스 수준에서 트랜잭션을 지정할 수 있습니다.

출처

2013-11-01 08:56:59

감사합니다. 매우 유용한 정보였습니다. 디버그 모드로 다시 테스트하고 위의 내용을 확인합니다. – lives

저장소에서 트랜잭션 인터셉터가 서비스 계층에 의해 시작된 transactionManager를 사용하지 않는다는 것을 알아 냈습니다. 저장소 프록시에서 검색은 "transactionManager"라는 이름으로 빈을 식별하기 위해 수행되며 사용 중입니다. spring jpa 데이터가 서비스 계층에 의해 시작된 트랜잭션의 일부가되기를 원하는 경우 수행 할 settign이 있습니까? – lives

스프링 데이터 JPA는

답변

관련 문제