What is the scope of Java – @ enabletransactionmanagement?

I'm trying to figure out where to put the @ enabletransactionmanagement annotation in the right place in the case of multiple javaconfig contexts?

Consider the following scenario: I'm in jpaconfig JPA configuration is available in AppConfig. Java There is a set of service beans in Java Then I was at rootconfig Write the entire application configuration in Java

I'm at jpaconfig Java defines a transaction manager and enables scanning of JPA repositories - because those expose transaction behavior, I put @ enable transaction management on JPA config and it works

However, some service beans also need to have transaction methods, such as accessing multiple repositories in a single transaction Should I also place @ enabletransactionmanagement on AppConfig? In my opinion, the implementation of this annotation seems to lead to the redefinition of some beans In fact, it doesn't seem to apply to me

@Configuration
@EnableTransactionManagement
@EnableJpaRepositories("com.mypackage.repositories")
public class JPAConfig {
 // ... here are EntityManager and PlatformTransactionManager beans
}


@Configuration
@ComponentScan("com.mypackage.services")
// @EnableTransactionManagement // - ???
public class AppConfig {
}

@Configuration
@Import({AppConfig.class,JPAConfig.class})
public class RootConfig {
}

Thank you for any suggestions

Solution

After some experiments, I seem to have found my own answer:

>There is no need to configure a context configuration of @ enabletransactionmanagement on each bean, although it does find that the annotation is actually processing @ transactional annotation on the created bean when registering the internaltransactionadvisor. > As far as I am concerned, I changed the context order in the @ import declaration. The persistenceconfig holding @ enabletransactionmanagement is the first After that, beans from other parts can declare transactions using AOP. > Another warning relates to the use of @ enabletransactionmanagement and @ enableglobalmethodsecurity Global method security uses bean postprocessing, which seems to connect the entire security configuration Beanpostprocessors were created early in the context startup, so you can't use declarative @ transactional (userdetailscontextmapper in my example) in any beans required to boot spring security - there was no consultant program created at that time!