Background jobs kicked off via `Transaction_SYS.Deferred_Call` sometimes take unexpectedly long to actually execute, and in the meantime the line/record they depend on gets closed by a user before the job runs, causing the job to fail. Is there a good way to prevent this timing race?

Q: Background jobs kicked off via `Transaction_SYS.Deferred_Call` sometimes take unexpectedly long to actually execute, and in the meantime the line/record they depend on gets closed by a user before the job runs, causing the job to fail. Is there a good way to prevent this timing race?

Set the queue_id parameter on the Transaction_SYS.Deferred_Call to route the job through a fast-executing batch queue rather than a slower default one — queue 4, the Touch Apps Push queue, in particular tends to execute nearly instantly rather than waiting in a slower queue's normal processing cycle. If a dedicated queue with these fast-execution characteristics is needed for this kind of scenario specifically, custom batch queues with their own configuration can also be defined under 'Batch Queue Configuration' rather than relying on an existing queue meant for another purpose.

Answer

Set the queue_id parameter on the Transaction_SYS.Deferred_Call to route the job through a fast-executing batch queue rather than a slower default one — queue 4, the Touch Apps Push queue, in particular tends to execute nearly instantly rather than waiting in a slower queue's normal processing cycle. If a dedicated queue with these fast-execution characteristics is needed for this kind of scenario specifically, custom batch queues with their own configuration can also be defined under 'Batch Queue Configuration' rather than relying on an existing queue meant for another purpose.

← Browse Developer Studio, deployment, and upgrades questions