Creating a timer-driven app

[eluser]bientek[/eluser]
I'd like my app to continuously check a database every minute to see if it should send out new emails. What's the best way to implement this in CodeIgniter? So far, I have considered a separate controller that gets initiated and managed independently of user sessions by an admin; it has an infinite loop with a 1-minute sleep, checking to see if there is any database input to act on, like new emails or admin instruction to start or stop.

See any problems with this approach, or perhaps a better implementation? I'm new to CI, so thanks for your help!

[eluser]WanWizard[/eluser]
Use a cronjob, and call the controller from the commandline?

Also make sure you have the logic in place to deal with concurrency. What if processing the data lasts longer than one minute, so the second process starts while the first is still running?
If you design this correctly, you're solution is much more scalable as well (more email to send? Just start multiple processes).

[eluser]bientek[/eluser]
Is a cronjob simply a possible alternative, or better?

I did not consider concurrency. Good point!

[eluser]WanWizard[/eluser]
From a development point of view, a cron job follows the flow of a normal URL request, so it's easy to implement, less complex then looping, and also less complex to stop once it's running (how do you currently stop a looping process?).

[eluser]bientek[/eluser]
Currently I would check the DB each loop for a STOP flag.

[eluser]smilie[/eluser]
Regarding concurrency, set somewhere in a table sort of 'config' / 'ini':
runnning 1 / 0 and each start of a cron should check there to see if it is not already running.

Cron is simply easiest / best way to do it :-)

Cheers,
Smilie

[eluser]WanWizard[/eluser]
For these kind of processes I use a message queue.

For example, my forum code has the option to send a new post to you via email, or send you a notification that there's a new post. When a user posts a new message, it inserts a new record into the message queue for every user that needs to receive something, with a task_id (in this case send out a notification or a message), a priority, a timestamp, and any key information the message processor needs. This has little impact to the application in terms of performance.

In the background, a scheduled queue processor (a CI controller) is started by cron. It fetches the first message (the oldest or the one with the higest priority), checks the task_id, then calls the method liked to that id to process the record. When finished the queue message is marked as processed (or deleted, depending on a config setting), and the controller ends.

To control update access to the controller, I use a semaphore system using a file, to make sure only one process can fetch a queue record at the time. I don't want to use database locking mechanisms, to prevent a possible performance impact on the application.

Depending on the load (i.e. the frequency of new records in the message queue), one or more concurrent message processors are started.

Currently, this is home-grown code, and not to scalable. I've got a conversion to beanstalkd (including CI library) on the todo list to solve that problem.

[eluser]bientek[/eluser]
WanWizard,

That sounds like a good solution.

My original solution assumed that CodeIgniter/PHP could have multiple threads, but it doesn't look like this is the case; i.e. if I create an infinite loop - even one that calls wait - it will tie up CodeIgniter/PHP from handling new requests.

[eluser]WanWizard[/eluser]
That depends on which type of Apache installation you use, and how it's configured.

The PHP sleep() function stops all PHP instances within the same Apache thread, but not in other threads. Problem is that often you don't have any control over the Apache config, which makes this tricky to use...

[eluser]bientek[/eluser]
Interesting. Sounds like since I'm running a VPS, I *could* configure Apache for my solution, but that it's probably going to be more difficult than simply using cron. My programming background is a bit stronger in desktop applications than web apps, so I'm learning as I go with this one.