Skip to content
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

Transactions get's stuck under curtain conditions #208

Open
anschnapp opened this issue Mar 19, 2024 · 2 comments
Open

Transactions get's stuck under curtain conditions #208

anschnapp opened this issue Mar 19, 2024 · 2 comments

Comments

@anschnapp
Copy link

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
Copy link

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

@anschnapp
Copy link
Author

anschnapp commented Mar 19, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants