Closed idmitrievsky closed 3 years ago
I see now, that the query
await ActionRelation.query.with_for_update(skip_locked=True).gino.all()
uses an implicitly acquired connection that is different from the connection acquired for the transaction (it is actually guaranteed to be different, because I specified reusable=False
).
Not sure how I missed it, sorry for the trouble!
Describe the bug I am trying to use
SELECT ... FOR UPDATE SKIP LOCKED
to prevent concurrent tasks from getting the same row. It seems like it doesn't work.To Reproduce I tried to annotate the example below with as much comments as makes sense. Let me now if something is unclear!
Expected result I believe, the test should pass.
Actual result Test fails because second worker has access to every row in the table.
Environment (please complete the following information):
Additional context I tried understanding this behaviour myself, but couldn't. It seems like according to Gino it actually starts two different transactions. But when I used the debugger to stop execution inside the transaction async context manager and tried executing
SELECT ... FOR UPDATE SKIP LOCKED
with raw SQL in the terminal – I got all rows as a result, as if no rows were locked by Gino.