Re: Questions about multiuser locking in database design

From: Jerry Gitomer <jgitomer_at_erols.com>
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

Original text of this message