[REBOL] Re: Multiuser database
From: petr:krenzelok:trz:cz at: 21-Mar-2006 12:17
SunandaDH-aol.com wrote:
> Pekr:
>
>> the only technique I can come up with right now is to
>> use some kind of time-stamp and regard .lock file being dead if the app
>> does not renew it in certain time period.
>>
>
> And even that isn't guaranteed to work:
>
> Two (or more) processes could be spinning waiting for the timestamp in the
> lock file to expire. They then all write the new lock file. They all think they
> have the lock, but only one truly does.
>
> You can reduce that risk by:
> -- read the lockfile
> -- wait for timestamp in the lock file to expire
> -- wait a further random fraction of a second
> -- read the lock file again: restart if it has an unexpired timestamp (cos
> someone beat you to it)
> -- write the lock file with your timestamp
> -- wait a random fraction of a second
> -- reread the lock file again: restart if it does not have your timestamp
> (because someone came in just after you and grabbed it)
>
uh, that all sounds crazy and because of what? Because unix can't
guarantee you file-lock if you particularly ask for it? What a weak
system ....
> But even then on a very busy machine (which is when all this matters) two or
> more processes could set exactly the timestamp, so they could not tell who
> owns the lock file from the expiry timestamp alone.
>
> To get around that, you need a guaranteed unique id (GUID). Write that to the
> lock file along with the timestamp. Then, when you reread the lock file, a
> changed GUID tells you you do not own the lock file
>
> Which simply opens a further problem of how you get a GUID. IP address is not
> sufficient (a caller may have multiple requests on the go).
>
what about checksum/secure? Should provide you enough of randomizer ....
but two same time values will give you the same result ... maybe you
could use checksum/secure/key and randomly generate the key or so :-)
-pekr-
