File sharing, locking, etc... between multiple users...

[Rob Cozens]

Jonathan, et al:

> I
> will try to create a centrally controlled version that does use a
> database/record locking approach.
>
> I guess options and flexibility are what is wanted.
>

The two factors you must deal with in any multiuser environment are 
data collision and record locking.

Data collision occurs when two or more users try to update the same 
file simultaneously, and can corrupt a file so that it is unusable.  So 
the focus here is assure that only a single user can write to the file 
at any one moment.  There are two general approaches to avoiding data 
collision: client/server systems and "uncoordinated individual user" 
systems.

A client/server system channels all file access through a server 
application.  In this approach, data collision is impossible, because 
the server does not process a user's request until it has completed the 
previous request [forgetting multi-threading for the moment] and 
because the server is the _only_ application to read from/write to the 
db file(s).  The downside to this approach is the client and server 
applications must be aware of each other, requiring interprocess 
communication (IPC).

An approach involving uncoordinated individual users relieves one from 
IPC considerations: each user app operates asynchronously, attempting 
to read from & write to the same file(s).  The downside is less 
efficiency, as (a) network packets may collide, and (b) the method of 
obtaining access involves hard drive reads & writes.  Here is how the 
FlexWare system I used to work with handled data collision issues...

The app requesting db access:

1. Opens a common control file
2. Reads the file's contents
3. If the file is empty writes its user id to the control file, else 
closes file, waits, and repeats steps 1 & 2 until the file is empty
4. Closes the control file
5. Opens the control file
6. Reads the file contents

If the control file contains the app's user id, the app

a.  Opens the index & db files
b.  Completes the read or write
c.  Closes the db & index
d. Writes empty to the control file
e. Closes the control file.

else the process loops back to step 1.

I believe the client/server approach is preferable, _if_ you are up to 
addressing IPC issues.  There is help available in that regard at the 
rev_ipc group at Yahoo! and open source examples in the Serendipity 
Library download at <http://wecode.org/serendipity/>.

See my post of February 18th (this thread) for comments on record 
locking.  I would only add that, because any open stack is 100% 
RAM-resident, record locking in Transcript is more complicated than 
record locking in HyperTalk.  That factor alone would lead me to select 
a client/server approach (otherwise how does one avoid writing the 
entire stack to disk with each update, and rewriting each active user 
besides the one who performed the update?).

Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)