Using a job to schedule other jobs? Best practices?

question
1

I need to execute a task, the details of which are largely irrelevant to this question, but basically will involve processing X number of Things. The number of Things to process to may change on a daily basis, and I’m not in control of that side of things, so I don’t think I can register recurring jobs for each Thing, as the Thing might not need to be done the next day, and I won’t know when it will next need to be done.

I pull the Things to process from a database, so, if I configure a job which will be repeated, does it seem reasonable to have that job add another job for each Thing to be processed?

thanks

1 Like
2

@sgrassie, sorry for the late answer. It is always difficult to discuss abstract things without precise context. In short, yes, you can create one background job inside another. But I can’t understand the time when Things are created. Why you can’t just create a background job each time someone create a new Thing?

1 Like
3

I can’t create a background job each someone creates a new Thing because I have no control or influence over when they are created, or when they are removed.

My application will have to monitor a table (and/or a fileshare for certain files) and then process certain business logic on each type of Thing which is present at that particular time.

So my idea is that I can use a recurring job to monitor the locations for Things and then queue another job for each one that has been found e.g.:

var targets = FetchScanTargets();

foreach (var target in targets)
{
    var id = target;
    _jobClient.Enqueue<Scanner>(scanner => scanner.Scan(id));
}
4

This method could be aborted after processing 50 out of 100 messages. In this case, the application can create duplicate background jobs for those first 50 messages. If you can handle this scenario, then everything is ok. Atomic batch creation of background jobs feature is still in my head only :slight_smile:

1 Like