Re: Questions about multiuser locking in database design
Date: Thu, 31 Jan 2002 00:11:42 -0500
Message-ID: <3C58D20E.5E25B52_at_erols.com>
Walt wrote:
>
> On Tue, 29 Jan 2002 23:58:43 -0500, Jerry Gitomer <jgitomer_at_erols.com> wrote:
>
> >To my way of thinking you should have three I/O operations:
> >
> > 1. Read
> > Read the image
> > 2. Read for update
> > Test and Set a lock flag for the image
> > If the image wasn't locked read it
> > else return an image in use error
> > 3. Write
> > Write the image
> > Reset the lock flag if it is set
>
> What I was asking about was the *mechanism* for locking. File locks? OS
> semaphores? Something else?
>
> I'd like to know what works best, so I can use that as the underlying traffic
> cop.
>
> I VERY much appreciate you taking the time to the answer!
>
> walt
Locks should be at a record level except when physically
reorganizing indexes.
If I remember correctly you are using flat files and therefore,
by definition,
won't have any indexes to reorganize, so in your case, use
record level locks.
Test and set is an atomic operation and is found in many machine
instruction
sets. use semaphores and read the manual very carefully to make
sure that you
have an atomic test and set capability for them. If not you
write a block of
code which everyone must go through in order to update and make
it serial in
nature. Much slower than hardware, but it guarantees data
integrity.
Jerry Received on Thu Jan 31 2002 - 06:11:42 CET