chore: adding row lock with behavior #1081
Conversation
To avoid organization deadlock
| @@ -62,6 +65,7 @@ impl Graph { | |||
| ) -> Result<Option<OrganizationContext>, Error> { | |||
| Ok(organization::Entity::find() | |||
| .filter(organization::Column::Name.eq(name.into())) | |||
| .lock_with_behavior(LockType::Update, LockBehavior::SkipLocked) | |||
There was a problem hiding this comment.
We are getting an organization, we do we need to lock that row?
Also, why would we want to skip that row in a case it's locked?
There was a problem hiding this comment.
from the docs:
With SKIP LOCKED, any selected rows that cannot be immediately locked are skipped. Skipping locked rows provides an inconsistent view of the data, so this is not suitable for general purpose work, but can be used to avoid lock contention with multiple consumers accessing a queue-like table.
my main motivation for this is but can be used to avoid lock contention with multiple consumers
to solve this update problem
I sent the PR mostly to share the app behavior with the team, I'm not fan of adding db locks
There was a problem hiding this comment.
So the result would be that anyone getting the organization would lock it (until the transaction expires) and that would make other, concurrent request skip that record?
There was a problem hiding this comment.
What I understand of this is that it blocks the select row and ignores the already blocked, by other concurrent calls.
I think is the same what you wrote.
Again I'm not happy with this also I'm using a small set of files for the upload test via ui.
There was a problem hiding this comment.
If that's the case, then I don't think it would be a good change.
There was a problem hiding this comment.
yeah not a problem 👍 the PR is more for me to have second thought thanks
To avoid organization deadlock