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

[BUG] Database Deadlocks #3319

Open
BlairCurrey opened this issue Feb 24, 2025 · 0 comments · May be fixed by #3320
Open

[BUG] Database Deadlocks #3319

BlairCurrey opened this issue Feb 24, 2025 · 0 comments · May be fixed by #3320
Assignees
Labels
type: bug Something isn't working

Comments

@BlairCurrey
Copy link
Contributor

BlairCurrey commented Feb 24, 2025

Bug Report

Describe the bug

Our database deadlocks in places where we open a new connection before an open transaction is resolved while at max connections.

This, basically: Vincit/objection.js#1137 (comment)

In our case, it may look something like:

await Quote.transaction(async (trx) => {
   await receiverService.get(id)
   await Quote.query(trx).insert({...})
})

We open a transaction then try to open a new connection from another db call not using the transaction (in receiverService.get). This results in the db call in receiverService.get (or similar) waiting to get a connection, which it never gets because the current connections never resolve (because its waiting on receiverService.get).

To Reproduce

  • Set the knex connection settings to a min/max of 1.
  • Change performance test to do 1 vu and 1 iteration
  • Run test and see it never completes

That's the easiest way but it doesnt just happen under the contrived scenario of 1 min/max connection. It happens at any number of VUs >= max connections.

Expected behavior

Performance tests should pass with 1vu/1iteration with max connection size of 1.

Resolution

Note that our current system makes some queries inside transaction blocks without using the transaction. We should probably evaluate if this behavior is correct on a case-by-case basis.

But in general, we either need to move the queries not using the transaction outside of the scope of the transaction (before or after), or we need to pass the transaction into the query. We shouldnt include anything more than necessary in the transaction to reduce transaction lock time and contention.

@BlairCurrey BlairCurrey added the type: bug Something isn't working label Feb 24, 2025
@BlairCurrey BlairCurrey self-assigned this Feb 24, 2025
@github-project-automation github-project-automation bot moved this to Backlog in Rafiki Feb 24, 2025
@BlairCurrey BlairCurrey moved this from Backlog to In Progress in Rafiki Feb 24, 2025
@BlairCurrey BlairCurrey linked a pull request Feb 24, 2025 that will close this issue
6 tasks
@BlairCurrey BlairCurrey moved this from In Progress to Ready for Review in Rafiki Feb 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Something isn't working
Projects
Status: Ready for Review
Development

Successfully merging a pull request may close this issue.

1 participant