flowerinthenight
For the succeeding lock attempts, should be the inserted row removed?
As per doc: ... When a lock is active, all participating processes will detect if the lease has expired by checking the heartbeat against Spanner's current timestamp. If so (say, the active locker has crashed, or cancelled), another round of SQL INSERT is attempted, this time, using the name format <lockname_current-lock-token>. The process that gets the lock during this phase will then attempt to update the token column using its commit timestamp, thus, updating the fencing token.
the <lockname_current-lock-token> is left in database, making unable to get the lock again once this is inserted.
Or do am I missing something please?
_current-lock-token part of the name is unique in every iteration of the next locking phase so there's no contention. Every iteration will generate a new record with that name. The lock holder will, in turn, cleanup those records during heartbeats (best effort basis) just to keep the size low; not as part of the algorithm itself.
