Describing Your Changes
Incase a vendor chooses to extend R2dbcTransactionManager and provide an autoconfiguration for the same, It conflicts with the already provided autoconfiguration resulting in context.getBean() throws exception as multiple beans are available.
For a scenario where a vendor wants their users to use the standard transaction manager for standard use cases and use the custom one for the vendor specific use cases, we should be able to access both beans. This change will mark the standard transaction manager as primary one and it will be given preference when auto-wiring a dependency for standard use cases. And for the specific usecases they can use the custom transaction manager using @Transactional annotation. For ex:
@Transactional(transactionManager = "customTransactionManager")
Comment From: wilkinsona
Thanks for the suggestion, but I don't think we should do this. Having two different transaction managers in the same application is rare and I think the auto-configuration should reflect that. With this in mind, none of the auto-configuration for PlatformTransactionManager declares the bean as primary and I don't think the auto-configured R2dbcTransactionManager should do so either. Thanks anyway.
If you'd like to explore solving your need in some other way, please feel free to open an issue so that it can be discussed.