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

From: Joel Garry <joelga_at_pebble.ml.org>
Date: 1997/11/25
Message-ID: <65f91u$593$1_at_pebble.ml.org>#1/1


In article <347AA052.37C_at_agd.nsw.gov.au>, Anthony Mandic <no_sp.am_at_agd.nsw.gov.au> wrote:
>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.

No matter how well written the application is, if the page is locked by someone accessing a different row that happens to be on the page where the row you want is, you won't get it. Telling people to make their records bigger so there is only one on a page is a pretty hard sell. Convincing programmers to write correctly is like herding cats. Good luck.

>
>> 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

-- 
These opinions are my own and not necessarily those of Information Quest
jgarry_at_eiq.com                           http://www.informationquest.com
http://ourworld.compuserve.com/homepages/joel_garry
"See your DBA?"  I AM the _at_#%*& DBA!
Received on Tue Nov 25 1997 - 00:00:00 CET

Original text of this message