HP3000-L Archives

July 2000, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Wirt Atmar <[log in to unmask]>
Reply To:
Date:
Mon, 17 Jul 2000 16:41:15 EDT
Content-Type:
text/plain
Parts/Attachments:
text/plain (27 lines)
Jim writes:

> When it comes to my data bases, I *am* that much of a paranoid delusional,
>  and in this case I would lock either the data set or the entire database
for
>  the entire process, no matter which method is used.

Actually, no method is perfectly safe, save kicking every other user off of
the machine. Locking the entire database doesn't prevent the problem I
outlined before. Rather, it would only forestall it until you released the
database/dataset locks. It would still be possible for you catch another
process in mid-transaction at that preciese moment you applied your
lock/delete/unlock, so that a particular master entry might have no detail
sets attached at that precise moment.

The best that you insure by locking the entire database is that you could
only disrupt one key value per accessing user, as compared to using the
repeating locks. In that situation, it could possibly, conceivably occur
every time.

But let me again emphasize how extremely rare this condition would be.
Unfortunately, with a multi-user database, life is full of risks. It's just
that you want to keep them manageable, something under 1 chance in a 100
billion :-).

Wirt

ATOM RSS1 RSS2