On complete, disable a task forever, even across db-scheduler restarts

[reda-alaoui]

Hello,

Sometimes we want to create tasks that should execute a limited number of times. Often these tasks should execute only once. They are often data manipulation tasks that should run in the background without disturbing the application nominal execution.

For now, we found a workaround that seems to work:

Tasks.custom("foo", Void.class)
        .scheduleOnStartup("once", null, Function.identity())
        .execute(
            (taskInstance, executionContext) -> {
              LOG.info("Hello World");
              return (executionComplete, executionOperations) ->
                  executionOperations.reschedule(
                      executionComplete,
                      executionComplete.getTimeDone().plus(1_000_000, ChronoUnit.DAYS));
            });

On complete, we reschedule the task to be executed in 1 000 000 days.

I find this workaround clumsy. This is a legacy I don't want to transmit to java developper of year 4760 :D I think this feature should be explicitely part of db-scheduler.

I have 2 ideas of implementation about that:

• Make scheduled_task.execution_time nullable. If null, we would consider the task as terminated forever.
• Add a boolean column disabled to scheduled_task to mark the task as disabled forever.

On the java side, we would add a new CompletionHandler implementation. Maybe named OnCompleteDisableForever?

What do you think?

[kagkarlsson]

Why not remove it completely (which is supported)?

man. 5. sep. 2022 kl. 09:02 skrev Réda Housni Alaoui < @.***>:

Hello,

Sometimes we want to create tasks that should execute a limited number of times. Often these tasks should execute only once. They are often data manipulation tasks that should run in the background without disturbing the application nominal execution.

For now, we found a workaround that seems to work:

Tasks.custom("foo", Void.class) .scheduleOnStartup("once", null, Function.identity()) .execute( (taskInstance, executionContext) -> { LOG.info("Hello World"); return (executionComplete, executionOperations) -> executionOperations.reschedule( executionComplete, executionComplete.getTimeDone().plus(1_000_000, ChronoUnit.DAYS)); });

On complete, we reschedule the task to be executed in 1 000 000 days.

I find this workaround clumsy. This is a legacy I don't want to transmit to java developper of year 4760 :D I think this feature should be explicitely part of db-scheduler.

I have 2 ideas of implementation about that:

• Make scheduled_task.execution_time nullable. If null, we would consider the task as terminated forever.
• Add a boolean column disabled to scheduled_task to mark the task as disabled forever.

On the java side, we would add a new CompletionHandler implementation. Maybe named OnCompleteDisable?

What do you think?

— Reply to this email directly, view it on GitHub https://github.com/kagkarlsson/db-scheduler/issues/315, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABKEHFUOOFKYLQ52ERIFVTV4WLJVANCNFSM6AAAAAAQEWHYLE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[reda-alaoui]

Why not remove it completely (which is supported)?

If you mean removing it from the scheduled_tasks table

According to my tests, on next application reboot (without changing the code declaring the task), the task will be rescheduled and executed once again. So it only disable the task for the application life.

If you mean removing it from the java code

We want the task to stay disabled until we remove its declaration from the java code.

[reda-alaoui]

So what do you think? :blush:

[kagkarlsson]

I think I see your use-case, you would like to use it similar to what you do with database-migrations using liquibase or flyway. Run once and keep the history to ensure it never runs again. This requires history, which I have so far tried to avoid. I suppose this might be a useful thing to be able to do, and you would just have to take care not to misuse (i.e. ever growing large table, in which case you are better off storing the history in another table)

I am already considering introducing a state column, which would cover you case as well. States might be:

• active
• dead-letter-queue / failed (failed too many times and requires manual intervention)
• paused / disabled. (make it possible to temporarily pause/disable recurring tasks via UI or similar)
• complete (your case?)

[reda-alaoui]

you would like to use it similar to what you do with database-migrations using liquibase or flyway

Exactly!

Let me know if I can help in any way :)

[matejuh]

We have also this use-case.