On 22/02/2006, at 5:00, "Jonathan Lynch" <[EMAIL PROTECTED]>
wrote:
1) User A reads the file, and determines it is not owned
2) In the few milliseconds between when User A reads the file, and
resaves
it, user B reads the file and also reads that it is not owned.
3) User A makes changes and saves the data
4) User B, who should have been locked out but was not, makes
changes and
saves his data, overwriting the changes made by User A.
My plan is to minimize the possibility of this type of collision by
having
the minimum possible time between reading a file and resaving it with
ownership. Secondly, I will include some collision detection code
That sort of thing can work quite well in scripted apps. I had to do
a similar thing where the rate of access was very low but it was
nonetheless important that there be no conflict. It worked like this:
1. User A reads directory and if the file is already owned, sleeps a
randomly short time and tries again.
2. On finding the path clear, User A writes a flag asserting
ownership and sleeps a randomly short(er) time.
3a. On waking again, User A reads the flags and if it is still the
sole owner, sets about its business.
3b. If, on this second awakening, User A finds another owner
contesting (i.e. a race condition slipped through the first check
above) then User A removes their own ownership claim and goes back to
the beginning.
Like I said, this is for low volume stuff but it is "perfectly"
effective in preventing conflicts arising from race conditions while
the random components avoid continuous synchronised failure. Setting
a flag file in the directory should be faster than reading, changing
and writing the content of the main file.
regards
David
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
