Best Practice For Job Repository - Shared Common Repository or Multiple Repositories?

Hi All,

I have a quick question to advise on how we should setup our job repositories in particular to support a broader rollout across a large enterprise. Is it ok to setup a common single job repository that we can share between multiple applications? The idea being this would be a managed service to help reduce the overall infrastructure required and to have a single point to monitor jobs.

My main concerns are around concurrency + ensuring rogue applications don't bring down the overall managed service. Any insight into the general scalability of a single repository would be appreciated.

There's nothing inherently wrong with using a shared repository, but you're right to be concerned about concurrency. By default the repository is setup to use serializable isolation. This could prove problematic if a lot of jobs are being kicked off, but it does safe guard against potential issues that would be caused by the same job being kicked off at the same time. However, if you have a good scheduling solution to ensure that won't happen, you can use a more forgiving isolation level.