Added safe relock function 

Required a changed in the lock function to return the lock ID instead of the unlock callback.
Hi Geoff,

Great point about the unlock vs id returned - I've had a similar thought,
unfortunately only after the commit :)
I'd vote for adding it as another parameter to the lock callback, what do
you think?
If you agree, I'd modify my commit later today and make another pull
request?

Our use case is based on identification of a primary and slaves in set of
processes to facilitate failover.
For now I'd like to use redis locks instead of zookeeper for this.

More concretely, I have a nodejs app tailing MongoDB oplog and publishing
selected events to Kafka.
I'd like only one process to be the primary and publish to Kafka, where
other 2 are hot standbys, immediately picking up when the primary dies or
becomes unresponsive.

The requirements are:
1) We need a TTL on the lock
2) We need to be able to extend the lock TTL to avoid releasing if the
primary is healthy (only the process that holds the lock should be allowed
to extend the lock)
3) technical speaking the unlock is not really necessary in my use case :)

While 1) was provided by warlock, 2) was not.
The implementation I am envisioning is along these lines:

console.log('Process is a slave');
warlock.lock('myLock', 2000, function (err, unlock, id) {
  if (err) { ... }

  if (id) {
     console.info('Process is the PRIMARY')
     // RUN COMPUTATION
     // in my case - process a batch of operations from MongoDB

     // extend the lock
     warlock.relock('myLock', id, 2000, ...)
  } else {
    // retry after a delay
  }
});

Of course any other feedback more than welcome.

Best,
Maciej

On Thu, Oct 23, 2014 at 8:44 AM, Geoff Wagstaff <notifications@github.com>
wrote:

> In lib/warlock.js:
>
> >
> > -        return cb(err, unlock);
> > +        return cb(err, id);
>
> Perhaps rather than changing the unlock function result, we can either set
> the lock ID as a property on the unlock function, or add it as another
> parameter to the lock callback. That way the API change is additive rather
> than breaking.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/TheDeveloper/warlock/pull/4/files#r19262984>.
>