Alternative implementation in Go #2
Description
I've been working on an alternative in Go, since I needed to support expiration, which gcslock does not support.
Your article was very helpful, thanks.
There are few places where I've diverged from your implementation, which you may (or may not) find useful.
Feel free to close the issue at your discretion.
I use generations (rather than metagenerations) to "refresh" the lock. I do this for 2 reasons: because the XML API (which I use) does not allow me to update just the metadata, and because I optionally allow the user to attach data to the lock (and update/inspect it - I use this to report progress of the running operation).
However, there is an advantage to this. The generation of an object is less predictable than its metageneration. Given that the metageneration is so predictable (sequential), I'm actually not convinced it is safe to delete the lock based on just the metageneration.
I do not retry using PUT (i.e. "create file"). Because of object immutability locking and unlocking a mutex is subject to the "once-per-second" quota. Contention from repeatedly trying to acquire the lock makes it harder to release it. So, after trying to optimistically acquire the lock, I immediately switch to using HEAD to test the lock, so I don't contend with DELETE, and only PUT once the lock is gone or expired. HEAD is also approximately 10 times cheaper than PUT, so it really is better to loop on HEAD.
I check for expiration based only on server time. I store a TTL in seconds in the metadata. I then use server date, last modification date of the lock and the TTL to determine if a lock is expired. Thus, local clock is one less thing to worry about.