artodeto's blog about coding, politics and the world

While i am dealing with cronjobs inside a private project, i run into some trouble with parallelism of cronjobs. A simple example would clear up this problem. Assume you have cronjob that generates cachefiles (like product descriptions or semi dynamic webcontent like cached rss feeds). You will end up by running a creation cronjob in an interval of x minutes. The problem that could happen is that a cronjob is already running while the next one is ready to go. You can deal with that problem by setting a maximum execution time in you script but this can lead into strange data and side effects. I want to solve this problem with two interfaces you can use. The first interface, called "Lock", is solving the problem with parallelism. If a lock is aquired you are not able to aquire a second one, meaning one cronjob not more. The second interface, called "Shutdown", is solving the problem with an early and controlled termination of a running cronjob. If the cronjob receives a shutdown, the cronjob can terminate itself i a good way. Both interfaces have a file based implementation. Unittests and also examples can be found inside the projects. The next idea I want to realize is an implementation of the Subject-Observer-Pattern. The general idea is that the first call of the cronjob is acting as a observer. The observer itself is chunking the work and split the work by calling (and observing) a number of cronjobs (of its own) as subjects.