OpenEuphoria

Re: EDS

• Posted by Kat <gertie at ZEBRA.NET> Mar 14, 2000
• 592 views

----- Original Message -----
From: "Everett Williams" <rett at GVTC.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Tuesday, March 14, 2000 1:10 AM
Subject: Re: EDS


> 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.

This was well documented in some early multi-cpu systems that used cpu
caches for retrieved data. After each cpu did it's thing, and modified the
data, it would write back the new data, and the file server would let all
the other cpus who read the data that their cache was no longer correct.
Then it was up to each cpu to request an updated version, see if the updates
impacted it, and if they did impact, then redo whatever they had done to the
old data unto the new data. Then of course the 2nd cpu could do a writeback
and the 1st cpu would get told it's data was now invalid. In some cases,
this would drop system speed to 10% or less of what was expected, ie a dual
pentium233 would run at single pentium60 output for that problem.

I ran into this problem in doing Ai, but with tight control over what is
serial and what is multithreaded, coupled with faster cpu than i had then,
the problem is reduced to figureing out what code is best threaded vs
nonthreaded. That takes it out of the realm of DB management, especially if
deletions are not permitted, and additions are time/origin stamped. It's up
to whoever has the data cached to decide to ask if the data has been
changed.

Kat