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


i come javaee background running on single server. i'm studying play framework build high performance scalable , elastic systems. realize play stateless , share-nothing , understand thing. also, read cap theorem , 12 factor apps. situations feel i'm still thinking javaee developer, ask how best design solution problems below.

imagine have system "requester user" creates offer. offer sent mobile devices of 10 other users. 10 users can respond offer, first 1 respond "get" offer (the others receive message saying "other user has accepted offer"). requester user receive e-mail saying offer done user x (the first accept).

the offer lasts 30 seconds. if no user responds offer within time, offer automatically closed , hence not accept more replies. e-mail shall sent requester user saying offer not accepted user.

everyday @ 20:00 system have fire e-mail admins reporting every offer, tried accepted them , "got it".

so here main 3 questions:

  1. how make sure 1 user accepts offer? database pessimistic locking best option serialize these requests, if incurs in blocking io? thinking optimistick locking jms server send e-mail, play not support xa transactions don't think it's idea. maybe using jms server, os akka, best option.

  2. how best strategy 30s timer? use asynchronous job, these jobs have high affinity current instance , don't think idea in elastic cloud, servers may go down in low usage periods. again, maybe akka way go? read akka has at-most-once delivery not sure if it's feasible this. maybe distributed quartz?

  3. for 20:00 report use scheduled jobs @every annotation. fire n reports in parallel, n being number of instances in environment. again, use database locking mechanism avoid this, lots of blocking io. minimize these blockings if had fine grained transaction control in javaee (requiresnew, etc) in play sure there more elegant way of doing this.

i prefer solutions , tools embedded in play framework, or third-party solutions aligned play philosophy.

thank in advance, renan

don't use quartz -- akka has equivalent functionality. without knowing scale requirements it's hard comment blocking io. there async db apis believe, , async api mongo. avoid blocking io, if db locking used.

for 30 second timer, use persistent storage, such database table represent tasks-to-be-done. server instance can perform task.


Comments

Popular posts from this blog

node.js - Mongoose: Cast to ObjectId failed for value on newly created object after setting the value -

gradle error "Cannot convert the provided notation to a File or URI" -

python - NameError: name 'subprocess' is not defined -