Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server
From: Anthony Mandic <no_sp.am_at_agd.nsw.gov.au>
Date: 1997/12/02
Message-ID: <34838DAD.7845_at_agd.nsw.gov.au>#1/1
> individual files and data structures rather than having one large
> kernel lock? Try reading
Date: 1997/12/02
Message-ID: <34838DAD.7845_at_agd.nsw.gov.au>#1/1
David Williams wrote:
> Imagine 1 page with 2 rows one it.
>
> 1. Page level locking
>
> User A updates row 1
> At the same time user B updates row 2. User B has to wait for
> User B to commit.
You're forgetting latency. There's no way that you'd ever get immediate concurrency as in your second scenario below.
> 2. With row level locking
> User A updates row 1
> User B updates row 2 (with no waiting).
>
> How can 1 be faster than 2 if user B has to wait?
The wait would be negligible. In scenario 2 you also have a wait (its hidden unless you think about it so you won't see it). It goes like this, a database server services request 1 then it services the next request (in this case 2). The wait is implicit. So you don't really gain anything.> Lock granularity is still a problem. Why do UNIX kernels lock
> > For a finely tuned application, row level locking
> > does *not* matter.
> individual files and data structures rather than having one large
> kernel lock? Try reading
Hey but they don't lock rows of text in a file do they?
-am Received on Tue Dec 02 1997 - 00:00:00 CET