-
Notifications
You must be signed in to change notification settings - Fork 38k
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
R2DBC ConnectionFactory bean .close()
method should be called/subscribed when available
#26991
Comments
I've transferred this issue to the Spring Framework team to see if they can add a support class to |
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. |
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. |
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 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. |
When Spring Boot autoconfiguration instantiates
io.r2dbc.spi.ConnectionFactory
bean implementingio.r2dbc.spi.Closeable
, the framework should have a custom destruction method invokeCloseable.close()
and subscribe to the returnedPublisher
.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 R2DBCCloseable
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
The text was updated successfully, but these errors were encountered: