HP3000-L Archives

November 1995, Week 5

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:
Robert Joseph <[log in to unmask]>
Reply To:
Date:
Tue, 28 Nov 1995 10:52:34 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (25 lines)
Item Subject: Message text
We have been using Allbase for a large system developed over the last 3
years.  Some of our experiences would confirm Terry's suggestion.  By
limiting the interactive update activity to a single table you can avoid
many of the headaches related to locking many tables.
 
We have found that page level locking worked best for us.  Row level
locking incurred too much overhead for multi row updates.  We also used
a logical locking approach for one function where we wanted to select
without any lock but prevent subsequent selects from seeing those rows.
 
In fact, after several iterations we altered many of our queries to use
the Allbase RU isolation level, which does not lock.  This allowed
rather broad queries to be issued.  The actual update logic than
required another select to confirm there had been no change to the row
since the first select (the classic "weak locking" strategy).
 
Another suggestion is to select the tuple id using the TID function,
then use that in the update statement.  This avoids locking on the
indexes, and speeds access to the table data.
 
Rob Joseph
The NPD Group
[log in to unmask]

ATOM RSS1 RSS2