Manual heartbeats?

[ddaeschler]

I would like to use this library in a serverless environment, and as such, I do not want node.js starting timers that will leave the instance running.

Instead, I'd like to be able to manually send a heartbeat to keep the lock active. That way I can implement the heartbeat as a REST call and keep the nodejs side stateless.

Thoughts? Is this possible somehow now without too much code mangling?

Thanks!

[tristanls]

Howdy,

Glancing through the code, it should be possible without too much pain to attach refreshLock() to the Lock object being returned by FailOpen.acquireLock. Then, instead of gating creation of refreshLock() on heartbeatPeriodMs being defined, refreshLock() would always be attached to Lock, and only the automatic kickoff would be gated by heartbeatPeriodMs configuration option. Additional maintenance of self._heartbeatTimeout would be required, i.e. don't schedule it again if heartbeatPeriodMs is not set, but I think that'd be it.

[ddaeschler]

Thank you. It looks like there may be a little bit of other state I'd need to carry outside the lock class for my use case as well (fencing token and the uuid if I'm looking at things corectly). Would you support a patch to allow the lock client to be used statelessly? Basically just making it so the state that is maintained inside the lock can be supplied instead.

[tristanls]

Ah, I think I misunderstood at first.

In that case, forget all the stuff I said, it seems like what you want is a utility to accept some parameters that will Do The Right Thing™ to refresh the lock given a table, lock name, and lock state.

How about adding additional top level static exports then? artisanalRefresh(lockState) probably along with artisanalRelease(lockState)? They'd be separate static implementations of refresh and release relevant bits.