in reply to Re^2: Race condition in my cron daemon
in thread Race condition in my cron daemon

Based on your description, it may be something else. If that doesn't fix it, let us know.

Replies are listed 'Best First'.
Re^4: Race condition in my cron daemon
by clinton (Priest) on Apr 10, 2006 at 19:02 UTC
    I couldn't get this DB lock working over the fork, so I've gone a different route:

    • Fork
    • Use Proc::PID::File to check that this job isn't running.
    • If it is:
      • Increment the number of attempts to start the job in the database
      • Select the no of attempts from the DB - complain if greater than X
      • Exit
    • If it isn't running:
      • Reset the no of attempts in the DB to zero
      • Run the job
    This way I avoid locking the DB at all.

    Perrin, thanks for your help

      Glad to hear you found something that works. Sorry I couldn't spot the problem in the original code.
Re^4: Race condition in my cron daemon
by clinton (Priest) on Mar 27, 2006 at 10:04 UTC
    Nope - still getting the same issue. I have added these lines to the code for the child process:

    # Child # Get rid of old database connections > $lock->{InactiveDestroy} = 1; > undef $lock; > undef $db; MyStuff::DB::clear_cache(); chdir '/' or die $!;

    I still get the same issue where the parent locks the 'jobs' table, then when it tries to use the same dbh to write the new PID, it hangs, waiting for the lock.

    This only happens sporadically, and only when the child process has something to do (so that it takes fractionally longer to complete than usual), but not always...

    Further help would be greatly appreciated...

    clint