playframework - What are Play Framework best practices for exclusive locking and programatic timers? -

I came from a background running on a single server from the background. I am studying Play Framework to create high performance scalable and elastic systems. I realize that the play is stateless and nothing is shared and I think that it is a good thing besides that, I read about the CAP theorem and the 12 factor app. But there are some situations where I feel like I'm still thinking of being a Java Aike developer, so I would ask for help to get the best solution to solve the problems below.

Imagine that I have a system where "requestor user" creates an offer this offer will be sent to 10 other users' mobile devices . All 10 users can respond to offers, but only the first one has to answer "offer" (others will receive a message in which "another user has already accepted the offer"). The requestor user will receive an e-mail, in which it will be said that the offer will be offered by user X (first to accept).

This offer lasts 30 seconds. If a user does not respond to the proposal within this time, this offer will automatically stop and therefore will not accept further replies. An e-mail requestor will be sent to the user, which states that his offer was not accepted by any user.

At 20:00 every day the system will need to fire an e-mail reporting every offer,

so my main 3 questions are:

1. How do I ensure that only one user accepts the proposal? Is the database pessimistic locking the best option in order to sort these requests, even if it starts blocking the IO? I was thinking of optimistic locking with JMS server to help send e-mail, but as the Play does not support XA transactions, I do not think it's a good idea to use only JMS server, Okay Akka will be the best option.

2. How is the best strategy for the 30s timer? I can use an asynchronous task, but these jobs have high relation with the current example and I do not think this is a good idea in an elastic cloud, where some servers can go down in less usage time. Then, maybe there's a way to go unexpectedly? I have read that Akka has the highest delivery, so I'm not sure that this is possible for this. Maybe Distributed Quartz?

3. 20:00 For the report I can use some scheduled jobs with @Every annotation but it will be reported in parallel, N, the number of examples in my environment is. Again, to prevent IO, I can use some database locking mechanism to avoid it. I can reduce these barriers if I had fine transaction controls such as Javanese (new, etc.), but in play I'm sure this will be another great way to do this.

I would prefer solutions and tools that have been embedded in the Play Framework, or have a third party solution to the alliance with Play Viewing.

Thanks in advance, Renan

Do not use quartz - equivalent to Akaka The functionality is difficult to comment about blocking IO without knowing the requirements of your scale. There are such ASCIN DB API which I believe, and there is an ASHINK API for Mongo. This must be avoided by blocking the IO, even if DB locking can be used.

For a 30 second timer, use continuous storage, such as the database table to represent work-to-done tasks, then any server instance can work.