Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@Transactional annotation can't establish dependency relationship between beans #22526

Closed
upcgaolei opened this issue Mar 6, 2019 · 4 comments
Assignees
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) status: feedback-provided Feedback has been provided type: enhancement A general enhancement
Milestone

Comments

@upcgaolei
Copy link

upcgaolei commented Mar 6, 2019

Problem Description

I use spring framework in my projects. In my application scenario, I need to use multiple data sources. In order to ensure that each data source transaction can be consistent and isolated from each other, I defined multiple transaction managers. I add the @Transactional annotation to the method that requires transaction processing and specify the specific transaction manager through @Transactional("transactionManager").

The Spring container not only manages the bean lifecycle but also includes the management of the dependencies between the beans. For example, the dependencies between the beans that is woven by the @Autowired and @Resource annotations can be established, which in order to close the application correctly according to the bean dependencies.

However, I find the approach that the @Transactional annotation specifies the 'transactionManager' qualifier does not establish the dependency between the beans, so that an exception may occur when the application is closed and the bean is destroyed. For example, when the transaction manager bean is destroyed first, if other beans that depend on the transaction manager bean have not been destroyed, there will throw exceptions.

Java code below

@Component
@Slf4j
public class UserManager {

    @Resource
    private UserDao userDao;

    @Transactional("transactionManager")
    public UserEntity updateUserInfo(UserReq req) {
        ...
    }

}

Question

I don't understand the design that the @Transactional annotation can't establish the dependencies between the beans. What is the starting point of this design? If it is reasonable and acceptable, then how can we ensure that the dependencies can be established correctly?

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Mar 6, 2019
@jhoeller jhoeller self-assigned this Mar 6, 2019
@sbrannen sbrannen added the in: data Issues in data modules (jdbc, orm, oxm, tx) label Mar 6, 2019
@sbrannen sbrannen changed the title @Transaction annotation can't establish dependency relationship between beans @Transactional annotation can't establish dependency relationship between beans Mar 6, 2019
@sbrannen
Copy link
Member

sbrannen commented Mar 6, 2019

However, I find the approach that the @Transactional annotation specifies the 'transactionManager' qualifier does not establish the dependency between the beans, so that an exception may occur when the application is closed and the bean is destroyed. For example, when the transaction manager bean is destroyed first, if other beans that depend on the transaction manager bean have not been destroyed, there will throw exceptions.

Can you provide a concrete, working example where such an exception occurs as well as the stack trace?

@upcgaolei
Copy link
Author

Yes, I will provide an example project to restore problem scenario.

@snicoll snicoll added the status: waiting-for-feedback We need additional information before we can continue label Mar 7, 2019
@upcgaolei
Copy link
Author

Hello, this is a concrete, working example demo, https://github.com/upcgaolei/spring-sample.

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Mar 12, 2019
@jhoeller jhoeller added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Sep 21, 2023
@jhoeller jhoeller added this to the 6.1.0-RC1 milestone Sep 21, 2023
@jhoeller jhoeller modified the milestones: 6.1.0-RC1, 6.2.x Oct 10, 2023
@jhoeller
Copy link
Contributor

jhoeller commented Mar 4, 2024

As of 6.2, we leniently tolerate late retrieval of existing instances during destroySingletons(), making late bean interactions possible during destroy method invocations even for retrievals from an on-demand supplier or async worker etc. After all, such late interactions were already possible for bean instances that got stored directly, and late retrieval was possible for beans without destroy methods (even if they were part of a depends-on arrangement in the other direction), so we may also tolerate interactions when retrieved on demand now: typically for validators and transaction managers, late-bound and/or potentially late-qualified.

@jhoeller jhoeller modified the milestones: 6.2.x, 6.2.0-M1 Mar 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) status: feedback-provided Feedback has been provided type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

5 participants