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).
Please see https://github.com/r2dbc/r2dbc-pool/pull/210 for unit test reproducing the issue and proposed solution - in case more full-proof solution is required connection dispose hook can be added on PooledConnection via Cleaner
R2dbc returns multiple pooled objects pointing to same database connection in case downstream gets disposed, e.g.
Monoconverted fromFluxor otherPublisher(e.g. any RxJava type)Flux.onError,Mono.onErrorinvoked from timeout operator on different schedulerFlux.takeDispose event in downstream causes ref.release().subscribe(); to be invoked that releases pooled references (without calling
preDestroyor any kind of logging event). As a result another pending invocationConnectionPool#createreceives 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).
Please see https://github.com/r2dbc/r2dbc-pool/pull/210 for unit test reproducing the issue and proposed solution - in case more full-proof solution is required connection dispose hook can be added on
PooledConnectionvia Cleaner