Added safe relock function 

Required a changed in the lock function to return the lock ID instead of the unlock callback.
Hi Geoff,

Hope you got my previous email.

I can make the fixed I mentioned, just let me know what you think about the
concept (so it could be useful for the lib).

Best,
Maciej

On Thu, Oct 23, 2014 at 9:59 AM, Maciej Dąbrowski <macdab@gmail.com> wrote:

> 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>.
>>
>
>