HP3000-L Archives

May 1996, Week 1

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:
Jerry Fochtman <[log in to unmask]>
Reply To:
Jerry Fochtman <[log in to unmask]>
Date:
Wed, 1 May 1996 06:52:37 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (52 lines)
At 09:56 AM 4/30/96 -0700, Thomas Harmon wrote:
>Is there any way to get around Images requirement of have the whole dataset
>locked when doing a DBPUT or DBDELETE? Our locking strategy is to only lock
>those particular entries that are capable of being changed which is easy with
>a MODE=6 and a lock list. Our problem is if any user has some entries locked
>for change mode, no other users can lock the whole dataset in order to do an
>add or delete. Surely there must be a solution other than not having entries
>locked during "think" time?
 
IMAGE's locking facility provides a 'logical' lock to a database in order to
protect the logical integrity of the shared data.  There is no requirement
that one 'logically lock' an entire dataset to perform a DBPUT or DBDELETE.
It is perfectly acceptable to place a logical lock on an item value which
does not exist as a pre-cursor to performing a DBPUT or an item value being
removed via DBDELETE.  The key point is that the applications that share the
data involved adhere to a locking strategy which protects the integrity of
the data while maximizing throughput associated with concurrent access.
 
Internally, IMAGE has a mechanism it utilizes on DBPUT/DBDELETE to
single-thread these activities in order to protect the internal structures
of the database itself.  For example, suppose an application performs a
DBPUT to a detail dataset with a single logical lock on the primary search
path.  However, this dataset has several other masters associated with it
and the chains in these masters (or new master entries in the case of
auto-masters) have to be updated to reflect the new entry. The same is true
with DBDELETEs.  IMAGE utilizes its internal mechanism to single-thread
PUTs/DELETEs in order to protect the structural aspects of all datasets
involved.
 
This DBPUT/DBDELETE single-threading mechanism for IMAGE structural
intregity has become a growing issue, particularly on the high-end systems.
HP is working on improvements to this process so as to provide for more
concurrent throughput while continuing to protect the structural intregity
of the database.
 
It should also be pointed out that it is not required that a search field be
the data item utilized for the logical lock.  It is perfectly acceptable to
conduct locking on a non-search item.  The key point to remember is that all
accessors have to utilize an agreed upon locking strategy.  Also, case must
be used in developing a locking strategy. Otherwise it is easy to get into
dead-lock situations.... :)
 
-- Jerry
 
===================================================
 
Democrary is a process by which the people are
free to choose the person who will get the blame.
                       -- Lawrence J. Peter
 
===================================================

ATOM RSS1 RSS2