If I were writing that, I would allow for the database going off-line while the program sleeps.

This is important if you are doing maintenance work. $dbh may no longer be valid when you wake up. I would put some code to try to re-connect (with sleep/retry) if the current connection is invalid.

I would also add some escape route - reporting the catastrophe, in case of "repeated failure" for an "extended period", for some definition of those terms.

Ok, so this would suffice:



#shut off website...
my $_sleepTime = (60 * 5);
my $_notifyTime = time() + (60 * 60);
my $_maxTime = time() + (60 * 60 * 6);
until($dbh->selectrow_array(qq{select `value` from `pagevars` where `n
+ame` = "eom_process"}) eq "ready") {
$dbh->disconnect();
sleep($_sleepTime);
$dbh = RWC::Sess::connect();
  if(time() >= $_notifyTime) {
   # Send an email notifying of still not running...
   $_notifyTime = time() + (60 * 60);# Reset timer
  }
  if(time() >= $_maxTime) {
    # Send notice of final disconnection and exiting
    # to manually fix... send this notice to my cell
    # phone to alarm me

    # Disconnect from database....  if connected
    if($dbh) {
      $dbh->disconnect();
    }

    exit;
  }
}
[download]


that makes logical sense... so while it is sleeping it does not use any memory right? what if it does take all that time everytime it starts again does it keep building upon the memory it had and then get larger and larger? or does the disconnecting from the database reduce the memory on the fly, even before perl is exited?

thanks again,
Richard

...so while it is sleeping it does not use any memory right?

No, not right: it still reserves whatever memory it had allocated when the sleep starts at line 7 (which includes a small amount of memory required for the countdown tracking) -- and it still uses a few CPU cycles to do the tracking.

what if it does take all that time everytime it starts again does it keep building upon the memory it had and then get larger and larger?

There's no obvious (to me) reason for the memory useage to grow when the sleep time expires. However, you're disconnecting from the database before the sleep, so you'll need someone with a better handle on garbage collection and memory release to get a knowledgeable reply. Note, though, that "starts again" is perhaps better phrased "resumes." sleep does not force reinitialization of anything, except as forced to do so by your code.

...reduce the memory on the fly, even before perl is exited?

Likewise, heed what wiser heads say about this, but my understanding is that that's not likely.

In the code of your dynamic website, I would add a check to the "eom_process" field in your database. If that field is not "ready", your script serves a static page "This site is now being maintained -- come back later" for your members. Meanwhile your colleague can do all maintenance required and when he is ready he sets the "eom_process" field to "ready" again and your members have access.

All you have to do is change that field to not "ready" when necessary. It would not take too much effort to write a small script to have a cron job do that for you.

I like this sort of idea. If you are shutting down the website, then a phased process is good. (1)Stop accepting new connections ("we are down for monthly maintenance at time X, expected time-up is time Y"). (2)For users logged in and doing things, try to find some "stopping point" so that their connection can be closed gracefully and their transactions wind up in a consistent state to the best of your program's knowledge. You will have to decide what to do if you can't get the users to log off themselves.

The DB maintenance program that is gonna run may change things to the extent that any pending changes that you might be aware of won't work right. Anyway get the DB to what you figure is a consistent state.

Rather than you shutting down at a specific time, you could have some I/F so that this maint program requests a shutdown, and when it is done, you reply back that you are shut down. When it is finished, it tells you that you can come back online. You want to come back up ASAP when it is finished. This I/F could be pretty simple with some file flags and perhaps some cell phone message if things stay down for too long.

Anyway the shutdown from your end may take a variable amount of time. And obviously what this other thing does takes a variable amount of time.

Crontab is the obvious choice.
I'm a little curious why you need to shut down the site database at all. If you use dates with your orders you should be able to limit the orders by date, thus any order placed after your "magic" time limit, is excluded from the selection...

If you absolutely must stop entries into the database, then perhaps you should simply hotswap to standby database and still avoid the downtime. I don't have an in depth understanding of your model, but I suspect there is room for improvement.