The auto-configured reactiveNeo4jTransactionManager may cause a failure due to multiple TransactionManager beans

[yangyaofei]

Bug report

In commit: b6467ed add rectiveNeo4jTransactionManager bean at class Neo4jReactiveDataAutoConfiguration

When use neo4j and other spring-data project, like jpa. And use @Transicational annotation.
Will get error like below:

No qualifying bean of type 'org.springframework.transaction.TransactionManager' available: expected single matching bean but found 2: transactionManager,reactiveTransactionManager

The workaround I use is add Neo4jReactiveDataAutoConfiguration to application like this: @SpringBootApplication(exclude = Neo4jReactiveDataAutoConfiguration.class)

But I think we need a proper way to avoid this error.

[wilkinsona]

@michael-simons am I right in thinking that you discussed this one a few months ago with @odrotbohm and you were in favor of making the reactive auto-configuration conditional on a ReactiveNeo4jTransactionManager bean?

[michael-simons]

Hej,

yep, that was our last common understanding.
We can't do on Flux / Publisher, as the Neo4j driver itself ships with them in all cases.

[meistermeier]

@wilkinsona The idea is to drop the dependency on the neo4j-java-driver with reactor dependencies in favour of a driver distribution that contains it as a shaded dependency. This way we could get rid of the (wrong) implication that users want to use reactive. Need to make up my mind and some technical experiments about the implications this might have.
But if this works out, the autoconfig for SDN should get much cleaner again.

[wilkinsona]

@meistermeier thanks, that sounds good to me. I guess we should change the auto-configuration to require a ReactiveNeo4jTransactionManager bean in the meantime and then we can switch to the new driver distribution (including managing its version) at some point in the future.

[wilkinsona]

I'm confused here as reverting the entirety of b6467ed does not result in a failure. I expected it to do so due to SDN requiring a transaction manager.

@meistermeier @michael-simons, has something changed in this area in Spring Data Neo4j since the Spring Data 2023.1.3 release train?

[meistermeier]

In 2023.1.3 we introduced the requirement for transaction managers on lower level than repositories: spring-projects/spring-data-neo4j@382214d
As a consequence you added b6467ed because the Spring Boot tests where failing.
(TBH at this point I just thought that you would add the bean definition to the test cases. ;) )
Unfortunately this resulted in problems if multiple tx managers where available, because b6467ed#diff-fd8daef5042f8d38d681a32aa30cb5edae5b4a02e762073d761ce8dc3bfc5662R72 now introduces the reactive Neo4j tx manager.
I later had to mitigate this in SDN with spring-projects/spring-data-neo4j@147a3fd to ensure that the right Neo4j tx manager is getting used.
This might solve all problems already but I am not yet sure if this would solve all scenarios.

As I said, the cleanest way would be to finally have a clean separation of reactive and imperative demands, based on the user requested dependencies and not our driver bringing project reactor as a dependency for every use-case.

[wilkinsona]

(TBH at this point I just thought that you would add the bean definition to the test cases. ;) )

We didn't want to do that as it would result in a breaking change for users when they upgraded to a new maintenance release. b6467ed was intended to fix the problem in a way that would not affect users. Unfortunately, it didn't quite achieve its goal as it just swapped one problem for another.

Given that the build now passes (locally anyway) with b6467ed reverted, I am going to go ahead and do that. We can then take things from there.