-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alternative implementation in Go #2
Comments
Thanks for the heads up. I'm also working on a Go implementation. Maybe it would be good to compare both our approaches when I'm done. I'll consider your comments here and think about possible updates to my blog post. |
From my side, I've made a simple Python implementation: |
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 usingHEAD
to test the lock, so I don't contend withDELETE
, and onlyPUT
once the lock is gone or expired.HEAD
is also approximately 10 times cheaper thanPUT
, so it really is better to loop onHEAD
.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.
The text was updated successfully, but these errors were encountered: