Re: Re: Simplest CGI Persistence Solution?

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.

Comment on Re: Re: Simplest CGI Persistence Solution?

Replies are listed 'Best First'.
Re: Re: Re: Simplest CGI Persistence Solution? by Trimbach (Curate) on Apr 02, 2001 at 16:46 UTC
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]

Replies are listed 'Best First'.

Re: Re: Re: Simplest CGI Persistence Solution?
by Trimbach (Curate) on Apr 02, 2001 at 16:46 UTC

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]