GithubHelp home page GithubHelp logo

foobarwidget / distributed-lock-google-cloud-storage-ruby Goto Github PK

View Code? Open in Web Editor NEW
17.0 17.0 1.0 157 KB

Ruby implementation of a distributed lock based on Google Cloud Storage

License: MIT License

Ruby 100.00%
concurrency distributed-locking google-cloud-storage mutex

distributed-lock-google-cloud-storage-ruby's People

Contributors

foobarwidget avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

Forkers

isabanin

distributed-lock-google-cloud-storage-ruby's Issues

Alternative implementation in Go

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.