in reply to CGI Display and Processes.

I also think that this screams for the use of a DB (SQL or Berkeley type). But if you don't control the processe(s) generating the 200 files and you cannot arrange for them to update the DB directly, then you would still require some kind of seperate process to monitor the files and import the data as it changes.

If you're running on Win32, then Win32::ChangeNotify could form the basis of a monitoring process that runs permanently and discovers when the files change.

Were I forced to do it without a DB, I would have the monitoring process mainatain the 20,000 items in memory in one of the "ordered hash" modules on CPAN.

Each time a file changes, it would read the file updating it internal cache. It would then write the ordered data to a timestamped file for the CGI to read.

Each time the CGI needed data it would use that from the latest timestamped file. As the CGI would only read the file, the scope for conflicts is minimal.


Examine what is said, not who speaks.
"But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
"Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

Replies are listed 'Best First'.
Re^2: CGI Display and Processes.
by fglock (Vicar) on Nov 19, 2004 at 18:39 UTC

    If you're running on Win32, then Win32::ChangeNotify could form the basis of a monitoring process that runs permanently and discovers when the files change.

    In Linux you can use SGI::FAM (File Access Monitor) - it is not only for SGI :)

      Is it? Looking at the source one can think that it is strictly for SGI FAM...

        I use SGI::FAM with Debian:

        apt-get install fam apt-get install libfam-dev perl -MCPAN -e 'install SGI::FAM'