Every time a new request comes in, the client transaction writes a JSON file into the queue directory. For the sake of no collisions, the file name can be a timestamp followed by some HTTP identifier -- perhaps the IP address.
The request script can then check if the agent is running by seeing if an agreed upon file is locked. If it is not, the request script forks off the agent. The advantage of a lock file here is that if the script exits abnormally, the lock is dropped, and so the agent will respawn on next request.
The agent moves through the queue, unlinking after each request is processed. Once the queue is empty, it exits.
If you do not require realtime response, you can also do this as a cron job. Fewer moving parts.
Finally, if you are worried about the DB fetches and they do not need to be current, you can use Storable or just use a local JSON file as cache.
#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.
In reply to Re^2: Constant SQL Querys to send "signals"
by kennethk
in thread Constant SQL Querys to send "signals"
by stewe
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |