Re: Refreshing stored data at administrator's signal
Hi. The touch file will definately work and I've used that myself but
in this case its inelegance bothers me. It's also another touch point
for administration. What I would probably do is put the state
information in the database itself. The script would keep track of the
age of its data and every 5 minutes or so it would check the state
information in the course of its normal operation. So when a user hit
causes the script to execute the last thing it does is see if it's state
data is more than 5 minutes old and if so refresh it. If the state
information has changed it would reload everything indicated right
there. U want to do this at the very tail end of the script so the
refresh doesn't delay the page draw for the user. This way u've avoided
expanding ur administrative footprint.
Colin Wetherbee wrote:[color=blue]
> I have an application that accesses some relatively static database
> tables to create drop-down <select> lists. As an example, one of these
> tables is a list of common commercial aircraft.
> At the moment (and not in a production environment), every time the
> drop-down list is generated for a web page, the script queries the
> database to retrieve the entire list of aircraft. I would prefer to
> retrieve the list of aircraft when each Perl interpreter starts and then
> not retrieve it again until the administrator sends a signal.
GE Aircraft Engines