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:
Reply To:
Date:
Wed, 1 May 1996 19:00:21 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (26 lines)
On  1 May 96 at 6:52, Jerry Fochtman wrote:
 
> 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.... :)
 
Another interesting 'feature' that I've seen used, is the fact that
the value of the item you lock on does not need to exist.  I recall
one implementation were there was an empty Manual master set, with
one item (the key value).  As soon as the key value was entered, the
application would 'lock' the value in the empty set.  After all the
data was entered, they would then lock the *real* data set (obviously
different then the empty master), put the record and unlock.  The, of
course, requires the program to have MR cap.  It effectively locks
the key value, without locking out all the users, for the duration of
the 'think time' and without actually 'putting' the record until the
use said, "Yes, this is right and I am done."  Interest
implemenation.  (P.S.  I may have the empty set wrong.  It might have
been an empty detail set.)
 
Larry Boyd
(These are my opinions and not those of my employer, HP)

ATOM RSS1 RSS2