Implementation to enforce convenient write locks on Postgres and Sqlite #8004
Conversation
…ng atomic transactions, for Sqlite created dummy operation to execute the task and for Postgres implemented advisory lock.
apurva-modi
force-pushed
the
7891-db-lock-implementation
branch
from
dbaa452 to
b4244f1
Compare
|
The errors are in affected code paths, so we may have something to unpick here. The strangest thing is that the test we created and tested locally was failing too. I'm rerunning the tests just to be sure. |
|
I run tests before pushing. |
|
Yeah, something seems to be behaving differently in CI - I'll check it out in the morning! |
| with transaction.atomic(): | ||
| operation = PostgresLock(key=lock_id) | ||
| operation.execute() | ||
| yield |
There was a problem hiding this comment.
I don't see operation.revert() here? That seems necessary because the type of advisory lock obtained is a session level lock, which should remain locked for the duration of the connection. I would suggest changing pg_advisory_lock to pg_advisory_xact_lock (reference). Note that for the transaction level lock functions (xact), there aren't corresponding unlock functions because it would be cleared by COMMIT or ROLLBACK of the transaction, including if the connection is closed.
There was a problem hiding this comment.
Ah, thanks - that's my bad for misleading @apurva-modi here. I'll submit an update.
Summary
Created a simple context manager to implement database write lock using atomic transactions.
…
References
Fix for #7891
Reviewer guidance
Testing checklist
PR process