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

Vote count:

0

I come from a JavaEE background running on a single server. I'm studying Play Framework to build high performance scalable and elastic systems. I realize that Play is stateless and share-nothing and I understand that this is a good thing. Also, I read about CAP theorem and 12 factor apps. But that are some situations where I feel that I'm still thinking as a JavaEE developer, so I ask for help how to best design a solution for the problems below.

Imagine I have a system where a "requester user" creates an offer. This offer will be sent to mobile devices of 10 other users. All 10 users can respond to the offer, but only the first one to respond will actually "get" the offer (the others will receive a message saying that "other user has already accepted the offer"). The requester user will then receive an e-mail saying that his offer will be done by user X (the first to accept).

The offer lasts for 30 seconds. If no user responds to the offer within this time, the offer will be automatically closed and hence will not accept any more replies. An e-mail shall be sent to the requester user saying that his offer was not accepted by any user.

Everyday at 20:00 the system will have to fire an e-mail to admins reporting every offer, who tried to accepted them and who actually "got it".

So here are my main 3 questions:

1. 
   

   How do I make sure that only one user accepts the offer? Is database pessimistic locking the best option to serialize these requests, even if it incurs in blocking IO? I was thinking about optimistick locking with a JMS server to help send the e-mail, but as Play does not support XA transactions I don't think it's a good idea. Maybe using only JMS server, os Akka, would be the best option.

   
   


2. 
   

   How is the best strategy for the 30s timer? I could use an asynchronous job, but these jobs have high affinity with the current instance and I don't think this is a good idea in an elastic cloud, where some servers may go down in low usage periods. Again, maybe Akka is the way to go? I read that Akka has at-most-once delivery so I am not sure if it's feasible for this. Maybe distributed Quartz?

   
   


3. 
   

   For the 20:00 report I could use some Scheduled Jobs with the @Every annotation. But that would fire n reports in parallel, n being the number of instances in my environment. Again, I could use some database locking mechanism to avoid this, with lots of blocking IO. I could minimize these blockings if I had fine grained transaction control like in JavaEE (RequiresNew, etc) but in Play I am sure there would be a more elegant way of doing this.

   
   

I would prefer solutions and tools that are embedded in the Play Framework, or third-party solutions that are aligned with Play philosophy.

Thank you in advance, Renan

asked 54 secs ago

Renan

6

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