in reply to Shared between mod_perl processes?

This has nothing to do with mod_perl vs cgi. Your user-specific data can be saved on the server with a simple database or on clients with cookies, and it's up to you to determine what format you save it in. If other users or their 'agent programs' need access to a user's data and you're only on one server, then the database approach or shared memory data structures are the way to go. SHM access is raw Perl and it's quite fast and easy if only the user's web access can change his shared data. If you wish to access this all from any client, a Perl program on any machine on the net can access a MySQL or PostgreSQL machine using the appropriate module, as long as that access is allowed by the database and its host's deny/allow rules.

Replies are listed 'Best First'.
Re^2: Shared between mod_perl processes?
by BerntB (Deacon) on Aug 19, 2005 at 17:23 UTC
    This has nothing to do with mod_perl vs cgi
    Uhhh... why do you think I asked about that?
    Your user-specific data can be saved on the server with a simple database or on clients with cookies
    I must have been very unclear. My problems was the size and complexity of my data. It would take time to load it.
    SHM access is raw Perl and it's quite fast and easy
    SHM works well? Thanks! I've always thought it was generally a bit of a problem (I've only experience with the old sysV). What CPAN-modules do SHM well?

    I can accept the SHM costs of (de)serializing, for now. It won't scale to many users or complex data, so I don't know if it is the long time solution.

    (Update: Fixed grammar.)

      I was wondering why you made such a point of mentioning mod_perl. The way Perl is executed has nothing to do with the rest of your question, AFAIK.

      SHM -- which is still SYSV :) -- works perfectly, and you can access it with no fear as long as it's Write Once, Read Many blocks. There's no need to use a module at all in this case. Even access for others to write is not difficult; you just build a common lock-block of bits (or bytes, if you can afford to be wasteful), which acts like a set of semaphores. No more tricky than file locking.

      If you intend Net-wide access, think again about databases. Your CPU + IO time will still be far less than the transmission time.