in reply to Simplest CGI Persistence Solution?

Well, your idea is what I've put together recently. It was very short, very simple, and very basic, which seems to be your main goal. Essentially my solution (which isn't accessible from this computer or I'd post it) uses cookies to store a session id ($session_id = time() . $$), storing Data::Dumper files on the server by that name. It's a little rough, but it works.

One suggestion: in a "Quick and Dirty" solution you can dispense with flock if your session ids are (virtually) guaranteed to be unique like in my solution. No one's going to ever be writing to the same file at the same time, so no need to lock the file. The only problem with this is that session files will collect on the server... to take care of this I set my CGI to wipe out all session files more than 2 days old every time it's run. You could do the same kind of thing with cron if you wanted.

The whole thing is like (maybe) 15 lines of code to maintain state. Why not?

Gary Blackburn
Trained Killer

Replies are listed 'Best First'.
Re: Re: Simplest CGI Persistence Solution?
by Tortue (Scribe) on Apr 02, 2001 at 16:26 UTC
    Your solution seems great for persistence across a session, for each user. But I'm looking to have persistence shared by all users. Or perhaps I don't understand your solution (don't kill me!:)

    I want web users to share access to the same data, stored in one file. Ideally the CGI is very fast, so the problem of parallel conflicting updates is reduced.

    I see two dangers:

    1. Damaging the integrity of the file
    2. Over-writing someone else's changes
    I definitely need to avoid (1.), but I could live with (2.) if it's unlikely to happen much in practice.

    I could avoid (2.) entirely if, as was suggested to me, the script locks the file as soon as it reads it and doesn't release it until it's done writing to it. As long as things are fast and nothing goes wrong with the script preventing it from releasing, this should work.

[reply]
      Ah.... sorry about that. I thought you were asking how to maintain state for individual users, not for things like a bulletin board and such.

      Yeah, if you have a single file that lots of users can write to you'll definitely need some sort of file locking mechanism (either flock or something else.) If you desperately need compatibility with systems that don't support flock you can use a flag system, that is, your script checks for the existence of a "lock" flag (this would be a separate file on the server called something like "lock" with no data in it.) If "lock" exists, the main file is locked and the CGI should not attempt to write to it. If "lock" does exist, the CGI first creates a "lock" file (preventing other instances of the CGI to write to the main file) then writes to the main file, then erases the lock file when everything's completed.

      Again, it's rough and ready, and you'll probably still have people step on each other's entries once in a awhile, but hey, it's better than nothing.

      The best solution would be to use a DB with some sort of locking mechanism built-in (either table level or row level). That way you can write to the DB all day long and not worry about inadvertantly erasing someone else's entry because the DB takes care of this whole issue.

      Gary Blackburn
      Trained Killer

[reply]

In Section Seekers of Perl Wisdom