HP3000-L Archives

November 1995, Week 4

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:
Mark Bixby <[log in to unmask]>
Reply To:
Date:
Mon, 27 Nov 1995 12:01:04 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (39 lines)
My organization belongs to a consortium that is developing a very large MS
Windows client - SQL RDBMS server system to run on the following RDBMS
products:
 
        HP Allbase under the HP MPE OS
        Oracle
        DEC's RDB
        Microsoft's SQL Server
 
The complete database will probably have around 500 tables, and at the largest
member organization will probably be used by as many as 400 concurrent users.
Transaction rates will be especially high during student registration periods
as about 75 of those concurrent users are students registering via a touch-tone
telephone interface, continuously, all day long.  Each update transaction can
involve "many" tables (10? 20?).
 
The people responsible for the high-level design of this new system felt that
native SQL database locking strategies would be too complex to implement for
"many"-table update transactions, and wouldn't scale well to offer decent
performance under peak loads.  As an alternative they have come up with an RPC
(Remote Procedure Call) logical lock server, where a special lock request is
created for each type of update transaction.
 
If you have experience with large scale, high transaction, interactive SQL
databases, I'd like to know which locking strategies you chose (i.e. SELECT
FOR UPDATE across a terminal read, SELECT FOR UPDATE re-read after a terminal
read, etc, or a non-native alternative) and how well you feel they perform.
The ideal strategies should be compatible with both an interactive human at a
keyboard, as well as the occasional long-running batch process.
 
PS: I've redirected followups to comp.sys.hp.mpe since I'm most interested to
hear from HP Allbase users since that's what we'll be implementing on here.
--
Mark Bixby                      E-mail: [log in to unmask]
Coast Community College Dist.   Web: http://www.cccd.edu/~markb/
District Information Services   1370 Adams Ave., Costa Mesa, CA, USA 92626-5429
Technical Support               +1 714 432-5865 x7064
"You can tune a file system, but you can't tune a fish." - tunefs(1M)

ATOM RSS1 RSS2