Transactions get's stuck under curtain conditions

[anschnapp]

Bug Report

Versions

• Driver: org.postgresql:r2dbc-postgresql -> 1.0.4.RELEASE
  (also tested with mysql and it seems to be stucked too, see other branch in example project)
• Database: 16.2

Description

It seems like under some circumstances connections get stucked, we face a big issue because of this where our service gets unresponsable and almost unusable.

We are using r2dbbc with postgres and spring boot.

After a long time of debugging we still don't find the root cause but we could successfully reproduce it.
Also we we're able to create a minimal reproduce example for this issue, you could review and try it out yourself here:
https://github.com/anschnapp/r2dbc-issue-531-reproducer
(their is also a mysql branch where you can see that this don't happen with other db drivers)

From our perspective multiple conditions have to be met to reproduce it:

• a method which uses multiple database operations inside one transaction (in our example a select and a update query)
• at least as much "parallel" caller of the method as capacity in the connection pool (so at least 10 if you use the default pool size)
• some mono/future conversions: like Mono.fromFuture(writeAndReadOperation(round).toFuture())

The last condition may appear to be a strange case. But there are some valid scenarios where such mono and future conversions are required.

We use it because of the usage of a caffeine cache which don't have a reactive api but a future based api.
Also we guess that other sequences of reactive chains might have the same effect here, it's hard to say without knowing the real root cause for this.

[agorbachenko]

There is an issue with the pool described in #198. Maybe the same, maybe not)

[anschnapp]

@agorbachenko i have seen it. i thought it's different because i don't have seen any cancelation signals while reproducing this issue.
also the transactions seems to be opened and not roll backed. i don't have seen any hint which goes in the direction that we have any cancelation or error handling here.