On 1 Jul 2004, at 08:06, Matt Sergeant wrote:
On 30 Jun 2004, at 19:01, Mike Chamberlain wrote:
On 29 Jun 2004, at 22:15, Matt Sergeant wrote:
Use atomic move in your file updates. Write to somewhere on the same filesystem (mount point) and move the file (or hard link and unlink the original).
Though in that case, the update of the file itself would be atomic (ie, you won't get a partial file being
read), but there is still a potential for another webserver to read the old (stale) file,
before the new file is created. At this point you need to consider if that is an issue, or
if you need to maybe write your own provider which does locking.
I'm confused. It sounds like you're suggesting the other webserver might be able to read the new file before the new file is created.
There's no race condition here, unless you think content should be uploaded before it's been written.
The race condition is if two people are updating the file at the same time.
ie...
Admin1 reads file1. Admin2 reads file1 (stale read, since there is no lock for update). Admin1 updates file. Admin2 updates file, Admin1's changes are lost.
What should happen is.
Admin1 locks file, reads file. Admin2 blocks waiting for admin1. Admin1 writes file, unlocks it. Admin2 reads file containing Admin1's changes. Admin2 updates file. Admin2 writes file.
That of course might not be an issue, say if there is only one admin.
Of course, the period between the read and the write could be quite long, given that the read might occur to
display the page to the admin, and the write could occur when the page is submitted. In that case obviously
unix locking isn't going to be the solution, but the existance of another file, created by an atomic operation
could be used to create the lock.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
