Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server

From: Anthony Mandic <no_sp.am_at_agd.nsw.gov.au>
Date: 1997/11/25
Message-ID: <347AA052.37C_at_agd.nsw.gov.au>#1/1


Perry Dillard wrote:

> Obviously Pablo has never written an OLTP Order Entry system where
> multiple users are constantly updating an inventory table and
> committing quantites to customers on the fly. If he had he would know
> that row level locking is absolutely essential and that page level
> will not let you see the realtime up to the instant available
> quantities for a given inventory item.

	Nonsense. I've worked on the development of something similar
	with Sybase. Regardless of whether the locking is row level
	or page, you won't ordinarily see the realtime up to the
	instant available current data until an open transaction
	has been committed. How can you see what doesn't yet
	exist? Row level locking doesn't change this fact.

> I'll admit that page level locking has its place, but row level is
> absolutely essential.

	Since when? The level of locking should be transparent to
	well written applications. It only becomes an issue with
	poorly written ones.

> And I don't believe anyone has tried to argue
> that row level locking carries no overhead. Of course it has more
> overhead than page locking. But it mostly depends on how many rows
> are actually being locked. If you keep one row locked in a header
> table during an update transaction, you aren't incurring a significant
> amount of overhead compared to a page lock. And you get the added
> benefit that someone else can be modifying the record right next to
> you since you don't have a whole page of data locked. This is quite
> critical when you have a multi-user application.

	One lock is one lock. Its not critical in a multi-user database
	unless the application being used is badly written.

-am Received on Tue Nov 25 1997 - 00:00:00 CET

Original text of this message