Skip to content
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

Open
ncruces opened this issue Dec 27, 2021 · 2 comments
Open

Alternative implementation in Go #2

ncruces opened this issue Dec 27, 2021 · 2 comments

Comments

@ncruces
Copy link

ncruces commented Dec 27, 2021

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.

@FooBarWidget
Copy link
Owner

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.

@orsinium
Copy link

From my side, I've made a simple Python implementation:
https://github.com/orsinium-labs/dimutex
It doesn't have healthcheck and leaves retries to the caller but otherwise should be about the same. I based it not on the Ruby implementation but on the article.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants