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)
_______________________________________________
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
