Fix r2dbc connection pool returning multiple pooled objects pointing to same database connection

[Azukovskij]

R2dbc returns multiple pooled objects pointing to same database connection in case downstream gets disposed, e.g.

• Downstream Mono converted from Flux or other Publisher (e.g. any RxJava type)
• Dispose called from different thread, e.g. Flux.onError, Mono.onError invoked from timeout operator on different scheduler
• Number of results is limited via Flux.take

Dispose event in downstream causes ref.release().subscribe(); to be invoked that releases pooled references (without calling preDestroy or any kind of logging event). As a result another pending invocation ConnectionPool#create receives same database connection, that has not yet been closed and has not finished processing in initial subscription.

This causes connection sharing issues on higher load that lead to lost cursor and data consistency issues (when transactions are leaked).

[62mkv]

a colleague of mine tried this patch and it looks like it sometimes leaves transactions un-committed.. Have you tried this in prod @Azukovskij ?

[Azukovskij]

a colleague of mine tried this patch and it looks like it sometimes leaves transactions un-committed.. Have you tried this in prod @Azukovskij ?

This might be related to multi-threaded access to the connection, that is not supported by most r2dbc drivers..

We are using r2dbc pool in prod with non-blocking statement queue that orders all statement execution. This is quite cumbersome solution so we are currently migrating to plain jdbc pool with virtual threads.

[kvaster]

This really fixes the problem. And the problem is really show stopper. Is there any chance to have this merged ? Or it's time to give up on r2dbc and move to jdbc with virtual threads... :/