OpenEuphoria

Re: EDS

• Posted by Everett Williams <rett at GVTC.COM> Mar 14, 2000
• 600 views

Irv Mullins wrote:

>On Fri, 10 Mar 2000, I wrote:
>
>> I need the ability to lock individual records, make a change, and write the
>> change back to disk (quickly) before unlocking the record for someone else to
>> use....
>
>The thought occurs to me that using Pete's RDC.e, I should be able to turn EDS
>into a db server, and write client programs for my users. That would accomplish
>two things: all the data would be accessed by one program, not several, and
>only one function could be performed at any given time, so that the issue of
>file/record locking would be moot, and multi-user capability would be more or
>less free.
>
>This seems too easy. Am I missing something?
>Irv
Other than tracking the IO of each user and their connection to the db, you're
not missing much. It is going to matter a lot if  "x" reads record 10, and then
"y" reads record 10. One or both or neither of them may write that record
back, modified. The order may mildly affect the integrity of your data, and
both "x" and "y" may find some fault with your handling of "their" data.
Multiuser access is not made transparent by server mediation unless the
server has clearly known and enforceable rules for such situations. Record
locking is one of the hardest areas to handle regardless of implementation.
Without timers and timeouts on both server and client, deadly embraces are
the inevitable result of locking. There are more than a few other such subtle
situations that result among other times when multi-threaded clients access
a non-threaded server...which is a possibility in this situation. The bottom
line is that nothing changes about the need for certain types of constructs
and rules in database access...only the location of the code.

If you really do serialize all IO as was indicated by your premise, you will
make the database almost useless for multi-user access. The time between
a read and a write of a single piece of data is wall-clock, human time, not
computer cycle time.

Everett L.(Rett) Williams
rett at gvtc.com