If the system does not have to be full realtime, each PC can write data in
his own file and an administartor (or a cron) can check for all of these
files and update the main one... then delete each individual files.
This way, each PC could know if his file have allready be processed, and
concurent acces is no more a problem.
Renaud
----- Original Message -----
From: "Brett Handley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 19, 2001 12:58 PM
Subject: [REBOL] Re: Concurrent access to data file
> Hi Christophe,
>
> Firstly I assume this bit of code is going to be running on each of the 80
> Pcs, not as some sort of server process. Is this the case?
>
> (1) If so, I think your proposed method is not going give you any of the
> protection you expect.
> There could be a "window of opportunity" for another process to get in
even
> though it should not.
> The weakness is that two processes could both succeed in "reserving" the
> token.
>
> (2) The other problem is the possibility that a program will fail due to
an
> error yet leave the token in place so that other processes believe it is
> locked.
>
> I suspect that you really need to trust file locking, but the problem is I
> haven't been able to work out if there is a way to get Rebol to lock
files.
>
> I attempted this:
>
> x: open/write/direct/binary %lock-file.dat
>
> and again in another rebol session which did not return an error so it
seems
> that Rebol appears to opening the file without exclusive write locking.
>
> With them still open I attempted to open the file with Wordpad.exe.
Wordpad
> did not open the file - complaining that another application had the file
> open - correct. To verify I close the opened ports and tried wordpad.exe
> again - this time it opened.
>
> So I believe that it would be good if rebol had file locking abilities.
>
> However I found that if you open a file like I did above, and try to
rename
> it you will cause an error - indicating the file is in use. This was
> confirmed when I belatedly read my site :-\ below
>
> http://www.codeconscious.com/rebol/rebol-net.html#Filelocking
>
> This indicates that a good idea might be for the client to open a tcp/ip
> connection with a rebol process on the server. This way if the client
> process dies, the connection should (?) timeout - thus dealing with
problem
> (2). I haven't tried it so ...
>
> Hope it helps.
>
> Brett.
>
> ----- Original Message -----
> From: "CRS - Psy Sel/SPO, COUSSEMENT Christophe, CPN"
> <[EMAIL PROTECTED]>
> To: "REBOL List (E-mail)" <[EMAIL PROTECTED]>
> Sent: Monday, February 19, 2001 8:39 PM
> Subject: [REBOL] Concurrent access to data file
>
>
> > Hi REBOLians:
> >
> > I'm confronted with a little but important problem...
> >
> > I'm using a block structure for storing data on a server.
> > 40 PC's -soon 80- could potentialy dump their data on the same time into
> one
> > single data file on the server.
> > Because we using Win NT -which I do not trust for reability-, I use a
> system
> > of token to insure concurrent access to the file:
> >
> > <snip>
> >
> > forever [
> > either all [(count<= 20) token?] [
> > count: count + 1
> > ;--- attempt to reserve token
> > if error? err: try [write token-file now (true)][
> > disarm err
> > return false
> > ]
> > wait 5 ;--- take delay to be sure token is written
> > ;--- try write operations
> > answers: load local-file
> > either error? err: try [save remote-file append load
> > remote-file answers (true)][
> > ;--- release token
> > delete token-file
> > disarm err
> > return false
> > ][
> > ;--- release token
> > delete token-file
> > delete local-file
> > return true
> > ]
> >
> > ][
> > return false
> > ]
> > ]
> >
> > token?: func [][
> > return not exists? rejoin [global-answer-path global-token]
> > ]
> >
> > </snip>
> >
> > The token is just a text file in this case, and gives the PC the right
to
> > "talk" to the server.
> > The proc checks for the existence of a token on the server, for a
maximum
> of
> > 20 times. If there's no token on the server, it writes its own one, dump
> the
> > data and release the token.
> > Empirically, I had to set a delay of 5 sec to ensure the token is
written,
> > because of the slow network connection.
> >
> > Well, my question is not about straight REBOL, but more a matter of
> > methodology :
> >
> > The procedure works, but, as you can imagine, it is not very efficient
for
> > so many PC working and dumping together.
> > How can I achieve a better performence regarding concurrent access in
> REBOL
> > on WinNT, which can garanty me no data will be lost ?
> >
> > Best regard,
> >
> > chr==
> >
> >
> > --
> > To unsubscribe from this list, please send an email to
> > [EMAIL PROTECTED] with "unsubscribe" in the
> > subject, without the quotes.
> >
>
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
>
>
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
