Yes, the table of tasks is how it is implemented now, but in this way I have to serialize and store all context data and variables and restore them in the second cron/daemon script. Sometimes context variables are big and anyway it takes some process time, which is not optimal [under high load]. It will be great to have something like 'after_response', if it is technically possible. 11.08.2011 23:17, David Precious пишет:
On Thursday 11 August 2011 18:00:37 Brian E. Lozier wrote:
I think you're better off having another server-side process to do this. For example, your dancer app adds a row to an "email_queue" table and then you have a cron job on the back end that looks for new rows and sends out the emails. This way it's decoupled from your application code. It's also easier to manage logs and notifications when you're not doing it under a web server environment.
I'd tend to agree, that sounds like a sensible way to handle it.
Another possible alternative would be to fork a new process that will do the stuff in the background, whilst the original process continues onwards to send the response back to the client.
That might be a little trickier and harder to debug, though, possibly.
-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130