When Spring Boot autoconfiguration instantiates io.r2dbc.spi.ConnectionFactory bean implementing io.r2dbc.spi.Closeable, the framework should have a custom destruction method invoke Closeable.close() and subscribe to the returned Publisher.

If a user application creates its own ConnectionFactory, it would be the user's responsibility to then close it. Although it might be nice to have a generic pre-destruction facility that looks for all R2DBC Closeable beans and closes them cleanly. The regular Spring bean destruction mechanism won't work here, since Spring Framework would call .close() but not subscribe to it, making it a no-op.

cc: @mp911de

Comment From: philwebb

I've transferred this issue to the Spring Framework team to see if they can add a support class to spring-r2dbc to handle this. We could then auto-configure the class in Spring Boot. I wonder if some kind of post-processor is needed to deal with this?

Comment From: jhoeller

I wonder whether we should revise the core bean destroy method handling to detect a reactive return type and automatically subscribe to it... @rstoyanchev does that sound feasible? Calling a close method with a publisher returned and then ignoring it seems entirely wrong.

Comment From: mp911de

When discussing asynchronous/reactive close methods, we should also consider what happens when a close method returns a future. This works today already, but there's no synchronization/error handling.

Subscribing to a close Publisher would make a lot of sense to be at least consistent with close methods returning a future.

Comment From: rstoyanchev

I agree that a close method with an async or reactive return type shouldn't be ignored and that it should be consistent with the handling of similar with a Future. The ReactiveAdapterRegistry might come handy for common handling of all known or registered types.

The question of synchronization is interesting too, whether to await completion (possibly with some configurable timeout) but also how do it, i.e. sequentially, in parallel, or some dependency sequence.