[tigger0jk]

> 1. Query the database to find all dormant accounts with a balance, which haven't been charged the fee this month.

> 2. Charge each of these accounts a fee

> 3. Setup a cron job to run this every hour

Note that if this job ever runs successfully, but takes more than an hour, you will double-count. Can easily happen if the box running these crons is overloaded. One fix is to automatically halt the job after 55 minutes, another would be to have the middle step be impotent, for each user you're doing the process on, ensure (ideally in a threadsafe manner) that they need the operation to be done still.

[tesseract]

The article didn't really go into the details of the implementation but my mental image was basically your second proposal: the deduction of the fee should happen in the same database transaction as the updating of a "fee-last-charged" timestamp, relying on the database for thread safety and allowing the cron job itself to be stateless (and inherently protected against simultaneous execution of multiple instances of itself).

[samatman]

This could still lead to a double-charge, though.

If some rogue deploy script creates fifty of the cron job, and weirder things happen every day, one of those could be checking the stale state during the transaction of another one. A classic data race.

Eliminating this problem is left as an exercise for the interested reader...

[alex_young]

Sounds like a good reason to use a pidfile or mutex so you can eliminate the possibility of any concurrent jobs.

[jayd16]

Why is this an issue? Are you not running the query and recording the charge in the same transaction??