The approach I would take is to have the the task processor have a
“completion” flag/timestamp in the database, and corresponding
“has_been_read” flag/timestamp, or something along those lines. Any time
the user requests a page in the app, check to see if there are any
completed, unread notices and use the :flash to notify them somewhere in
the layout. Think along the lines of a “New Mail” alert on a portal or
If you want something more proactively pushed out, maybe because the app
window gets left open idle for long periods after task submission, maybe
have a div in your layout reserved for that sort of notice and have a
periodically_call_remote() check for newly completed jobs and put an
elert in the div. Use it sparingly, though, to save the server from
thousands of status checks a minute. Maybe only bring it into play in a
view when the user has a pending submitted task.
Jakub N. wrote:
Dave T. firstname.lastname@example.org wrote:
However, after further thought, I’m wondering why you need all this
complexity? The only reason I can see why you’d need to have the Rails
app check the db every few seconds is because you are caching something.
Each user of my application can send a task (a request) for which the
calculating time may vary from one up to several minutes. So it’s
obvious that I’m forced to make him wait. But I don’t want to. I think
that if I used a rails app to submit tasks and another app to give the
response I would need a trick to notify a user that his task was
calculated. That’s the reason I wanted to check the state of database
to find out which tasks of which users are finished.
Maybe should I use a queuing system or something like that?
Performance is the issue. I will have about 2000 users, and wait for
demands of about 100 users at once.