-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Row locking support in find*()
queries (via FOR UPDATE
)
#17136
Comments
Yes, I too have a use case where I want racing reads to block. |
Is this a duplicate of #5983? |
Yep, sounds similar but a bit ore specific maybe. Will clean up when we look at the issue in depth. |
Same here.
Getting this error when two threads are inserting the same user, the read should to see if the user exists if another transaction is working on it. |
The current work-around is to either use This is important if the activities before updating the row involves other side effects that we definitely don't want to happen if the transaction would fail. |
Any news / plans regarding this feature? |
Another friendly ping. I have that exact user create error. But also am trying to avoid accruing interest on a loan multiple times in the same day on a background job that might retry randomly. |
find*
queries
find*
queriesfind*
queries (via FOR UPDATE
)
Is there any plan to add "lock for update" feature to Prisma transactions? |
yes, I have the same requirement, when deleting a record another request can access it which should not happen. |
find*
queries (via FOR UPDATE
)find*()
queries (via FOR UPDATE
)
Is there any plan to add "lock" (shared, exclusive, update... etc lock) to |
Problem
I just migrated from Sequelize and was quite a fan of Prisma for being type safe. Would Prisma be able to support
SELECT FOR UPDATE
row locking like Sequelize supports? Understand that Optimistic locking is preferred by Prisma but it would be great if we have the row locking mechanism too.My problem: When multiple requests call this function concurrently, while first transaction is still processing, the subsequent transaction will see that the user is still active and do the processing again. If we could avoid it by locking the row, that would be great.
Suggested solution
const user = await tx.user.findUnique({ where: { id: user.id }, lock: FOR_UPDATE });
So, the user record with specific id is locked till the transaction is completed.
Alternatives
Additional context
The text was updated successfully, but these errors were encountered: