nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Sort Jobs in AcquireJobsCmd

frauke

Hello everybody,

I would like to have a guarantee that jobs are executed in the same order as they are created.

Wouldn't it be useful if they are sorted (by timestamp? by ID?) while reading them from the database?
I mean to add an order by clause to the statement "selectNextJobsToExecute" in the Job.xml.

Best regards
Frauke

Find more posts tagged with

Comments

frederikherema1

Why do you want to have such a guarantee? Ordering by timestamp still doesn't absolutely guarantee the job is executed first. The only guarantee is that it will be "passed on to a thread" in the pool before another (smaller timestamp), no guarantee about which job finishes first.

Also, what to do with jobs with a due-date? So there is not really a straight-forward way of deciding any "priority" mechanism that is generic.

frauke

Hi Frederik,

we have a kind of mass production process where a number of sub processes (call activities) are executed within a multi instance task. Since the user configures the order of the objects to be processed, we need to assure that the sub processes are at least started in the given order.

The objects we process are id cards which are personalized and printed on a card printer. The mass production has to be executed in the defined order.

A first-in-first-out mechanism would be sufficient in any case.

Best Regards
Frauke

frederikherema1

I see where you're coming from… There is nothing on the roadmap for this right now, but it's a valid point of "pluggability". Unless you want alter the activiti-source-code (JobAquireThread) for your purposes, there is another "workaround" you may want to consider currently:

- Use an external "pool" of things you want to see executed
- User service-task to queue the work and have a signal-task right after it
- Once external "worker" (which works FIFO

) is done, it signals the execution, associated with the piece of work that has been done