bugsbunny has asked for the wisdom of the Perl Monks concerning the following question:

does anyone know of a generic way to store sql-select-result (or as HASH on hdd) on the web server (system-wide, not session-wide) so that I can reuse it.

I'm talking for small result set.
I just want to store web configuration and some other small pieces on the web-server, instead of making the roadtrip to the DB.
As further question, if I have several web servers I will need to store some timestamp on the DB server, so that the other web server can recognize when change has been made, so that it can sync itself with the changes..

Replies are listed 'Best First'.
Re: DBI : local persistent storage
by Thilosophy (Curate) on May 25, 2005 at 08:02 UTC
    If you are using mod_perl or FastCGI you can store the data in memory, using a persistent variable (such as a package global). That is very easy to do, but does not work with vanilla CGI. If the data needs to be periodically refreshed, it cannot be shared among the mod_perl processes, but if that data is small, at least the memory penalty of having to store many copies (one in each process) is not an issue.

    You can store (almost) any kind of Perl data to disk (or shared memory) with the core module Storable.

    If you do not want to roll the code yourself, check the various Cache modules on CPAN.

    As for the timestamp, I would include that in the cached data. You can then compare it after retrieving from the cache.

[reply]
      Thilosophy has some good suggestions, and I'll second the one for Cache::FileCache as a quick and easy way to get things cached locally.
[reply]
        The only trouble is, it's dirt slow. It's slower than a simple query on MySQL. You'd be better off using Cache::FastMmap.
[reply]
Re: DBI : local persistent storage
by merlyn (Sage) on May 25, 2005 at 11:58 UTC
    Keep in mind that this may be an negative-effect cache, unless the rules for invalidation are merely time-based. The moment you start analyzing the data to see if it's time to blow the cache, you can be in the territory where it's easier to just ask the (tuned) database to give you the query results again. Databases are designed to process queries fast; it's good to let them do what they are good at.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

[reply]
Re: DBI : local persistent storage
by bugsbunny (Scribe) on May 25, 2005 at 07:52 UTC
    I seem to found what I'm searching :").
    http://search.cpan.org/~nachbaur/Class-DBI-Cacheable-0.03/lib/Class/DBI/Cacheable.pm

    The only thing left is inter-web server syncronization, but anyway for now I was interested for information purpses..
    sorry for wasting your time..:"(
[reply]
      ufff... now that I look at the Class::DBI::Cachable and Class::DBI::ObjectCache it seems a little bit more weird than I expected...
      It seems that it caches only the ->retrieve() call, but not retrieve_all().
      On the other hand the cache has to be build on the Application level, but later reused on Session and/or Page level.
      Probably wiser solution will be to put some Application code to build HASH on server startup so it stays in memory (for the configuration data).
[reply]

Back to Seekers of Perl Wisdom