Платформа Play: влияние заданий на модель без сохранения состояния

Одна из замечательных особенностей платформы Play состоит в том, что она полностью не имеет состояния и ориентирована только на запросы / ответы. Это действительно приятно, поскольку позволяет мне развернуть мое приложение в облаке и масштабировать количество экземпляров воспроизведения за моим балансировщиком нагрузки, не беспокоясь о репликации состояния (сеанса) ...

Однако недавно мне потребовалось выполнить некоторую логику приложения вне HTTP-запроса, и я обнаружил, что Play имеет возможность определять задания, которые полностью управляются фреймворком. Звучит великолепно, но возникает вопрос: как эти рабочие места вписываются в модель без сохранения состояния, которую использует Play?

Допустим, у меня есть задача обслуживания, которая должна выполняться каждый час, и я определяю для нее запланированное задание. Если я затем разверну несколько экземпляров Play за балансировщиком нагрузки, будет ли это задание запускаться одновременно на каждом экземпляре? И если да, то что было бы хорошим подходом для обработки заданий, которые должны выполняться «исключительно»?

Я думал о создании нового экземпляра воспроизведения на некластеризованном сервере, повторно используя модель JPA существующего ( кластеризованный) экземпляр (и, таким образом, подключение к той же базе данных). Этот новый экземпляр будет содержать только задания обслуживания, и, поскольку он размещен на некластеризованном сервере, нет риска одновременного выполнения задания. В то же время это позволило бы мне полностью сохранить мой существующий кластерный экземпляр без сохранения состояния и упростить размещение и балансировку нагрузки. Будет ли это хороший подход?