1

When running several scheduled tasks on multiple servers, Shedlock seems great, but sometimes, we need to halt some of the tasks for a short or long period too. Of course, it is possible to control each task with additional properties/flags, but my suggestion is to use Shedlock for this too, and introduce a logical "node/server" for the task we wish to stop, and update the row in shedlock-table with a lock to this node, and set a lockedAt time in the future, and a lockUntil to future + 1 second (so longer than maxRunning is not triggered). Then it will start again automatically, or we can go in and move the time further into the future if needed.

Any thoughts on this kind of use for Shedlock... smart or bad practice? It is still used for locking, just locking the job to a logical fake server.

Joakim
  • 13
  • 2

1 Answers1

0

It is possible to (mis)use ShedLock for this. The update you are looking for can look like this:

update shedlock set lock_until = :future, locked_at = now(), locked_by = "manual" where 
      name = :name and lock_until < now()

The important part is the condition lock_until < now() which prevents meddling with an existing lock for a running task. You do not have to set locked_by since it's mostly ignored by the library. It's just better to set it just in case someone else wonders why the tasks are not being executed.

Lukas
  • 13,606
  • 9
  • 31
  • 40
  • Ok, thanks, yes doc mentions update is possible, but not add/delete rows, trying to figure out, or come to terms with how much (mis)-use it is, since still using Shedlock for locking, but to node "manual". Using locked_by was in the plan, to visualize it in an interface. But had skipped the part where lock_until < now(). Doc said it caches the previous lock in memory, so didn't plan to "meddel", instead just run its course... and easier to overwrite manually if needed, without waiting for existing. The poc worked great, but team not totally convinced about this (mis)use, so time will tell... – Joakim Apr 09 '21 at 09:08
  • It's misuse just in terms that it's something the library is not designed for, but there should not be any issue. The cache only contains the information that the row in the table already exists so we do not try to insert it over and over. I will clarify the doc. – Lukas Apr 09 '21 at 15:28