question (<@U013V6T7UMC> <@U018PQSEPDE> <@U01867G8...
# dev
o
question (@Barak Amar @Itai Admi @Ariel Shaqed (Scolnicov) maybe you’ll know): why are we using advisory locks to manage write concurrency control to the branch? from the looks of it, we get the same guarantees by doing SELECT FOR UPDATE to get an exclusive lock for committing, merging, deleting branches, with SELECT FOR SHARE when reading the staging token for writing entries to it. It’s simpler since it removes the branch locker and extra conn pool (and avoids the double round trip/double tx overhead). what am I missing?
a
I think it's in order to satisfy the very particular requirements for concurrent commits and uploads: 1. Commits wait for concurrent uploads but fail immediately for concurrent commits 2. Uploads fail immediately for concurrent commits. So you need an atomic for detecting concurrent commits, and a RW lock for blocking commits versus uploads. The second lock is used as an atomic (performance doesn't matter here).
o
can’t this be achieved with select for update/share nowait?
a
Not AFAICT, unfortunately. To get a commit lock, you SELECT FOR UPDATE. Now... if you say "NOWAIT" then commits don't wait for concurrent uploads. If you don't say "NOWAIT" then commits wait for concurrent commits.
o
nowait will cause the lock to err instead of waiting. since select for share is exclusive with for update i think it should work..? not sure what i’m getting wrong?
a
AFAIK the requirement is that commits wait for all concurrent uploads to finish. If multiple uploads
SELECT ... FOR SHARE NOWAIT
then they proceed concurrently (good!). But now when a commit tries to
SELECT ... FOR UPDATE NOWAIT
it errors out - the requirement is to wait. (If the commit instead runs
SELECT ... FOR UPDATE -- YES, WAIT
, then this case works, but now commits wait for each other instead of erroring out.)
b
The locking level for the branch locker is above the references we manage in the database. if the concern is the update itself I think we can share the transaction we opened. The other way around is a bit tricky. At first I was thinking on managing row level locking to get the same effect.
(also they suppose to be faster)