[REBOL] Re: Concurrent access to data file

[CRS - Psy Sel/SPO, COUSSEMENT Christophe, CPN]

Thanks for the suggestion, but the system HAS to work in real time: the
results file have to be processed immediatly.

Thanks anyway !

Regards,

chr==


> -----Original Message-----
> From: Renaud [SMTP:[EMAIL PROTECTED]]
> Sent: maandag 19 februari 2001 13:38
> To:   [EMAIL PROTECTED]
> Subject:      [REBOL] Re: Concurrent access to data file
> 
> 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.
-- 
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the 
subject, without the quotes.