Tim, You are right - I already have redis in my stack, so that's the circumstance this was born out of. Given that I have redis in the stack, I wanted to avoid yet another (node or otherwise) server component just to maintain locks. Also, with redis there is already an algorithm available in the docs at http://redis.io/commands/setnx that seems robust, so it made sense to simply implement that.
Of course, this probably doesn't make sense if redis isn't already part of the stack. Regards, Rakesh Pai On Tue, Jun 19, 2012 at 3:22 AM, Tim Caswell <[email protected]> wrote: > Nice work. Though I wonder why a simple out-of-process node instance > wouldn't be enough. (it could even live in-process for one of the node > processes) Node is single threaded and such locks are trivial to write. > hald of the code would the protocol used to talk to the node process. I > would estimate about 40 lines of code to parse netstring framing > (https://github.com/c9/smith/blob/master/smith.js#L138-176) and then simple > JSON parsing for the message body. > > If you already have redis in your stack, then I can see how this makes > sense. But if not, it seems like overkill. > > On Mon, Jun 18, 2012 at 4:38 PM, Rakesh Pai <[email protected]> wrote: >> >> I put this up on github a couple of days ago: >> https://github.com/errorception/redis-lock >> >> It's an implementation of a locking primitive using redis. It's great >> for when you want to ensure that you don't run into concurrency issues >> when using the node event loop heavily, or with multiple instances of >> node. It doesn't block the event loop at all, yet ensures that your >> functions execute in order (across processes), to ensure integrity. >> it's kinda niche, but when you need it you need it badly. I've been >> using this myself on http://errorception.com kinda heavily, and it >> seems to do the job very well. I've tried hard to keep the API real >> simple - just one function call! Depends on Redis, because I wanted >> the lock to be sitting out of the node process, so that multiple >> (node) processes can find out about it. >> >> Feedback welcome, of course. Let me know what you think. (My first >> node thing on github! Also, my first github thing! :D ) >> >> -- >> Rakesh Pai >> Mumbai, India. >> http://rakeshpai.me/ >> http://twitter.com/rakesh314 >> http://www.google.com/profiles/rakeshpai >> >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en > > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en -- Rakesh Pai Mumbai, India. http://rakeshpai.me/ http://twitter.com/rakesh314 http://www.google.com/profiles/rakeshpai -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
