Play Framework: Impact of Jobs on the stateless model

Question

One of the great things about the Play framework is that it is fully stateless and only request/response-oriented. This is really nice since it allows me to deploy my app to the cloud and scale the number of play instances behind my load balancer without having to worry about state (session) replication...

Recently, however, I needed to execute some application logic outside of an HTTP request and found out that Play has the possibility to define Jobs which are fully managed by the framework. Sounds brilliant but it raises the question: how do these jobs fit into the stateless model that is used by Play?

Say I have a maintenance task that needs to run every hour and I define a scheduled job for that. If I then deploy multiple Play instances behind a load balancer, will that job be started at the same time on each instance? And if so, what would be a good approach to handle jobs that need to run "exclusively"?

I was thinking of creating a new play instance on a non-clustered server, re-using the JPA model of the existing (clustered) instance (and thus connecting to the same database). This new instance would contain only the maintenance jobs and since it's hosted on a non-clustered server, there is no risk of a job running simultaneously. At the same time, this would allow me to keep my existing, clustered instance completely stateless and easy to host / load balance. Would this be a good approach?

Answer 1

I would recommend to cluster the job too. You could set a semaphore in the database to ensure that only one job is running. Another idea is to have a look at the Akka-Framework, which will be included in Play 2.0. I think it has build in mechanism with handle this problem, but I'm not sure. I haven't experiences with akka.