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

In article <34838DAD.7845_at_agd.nsw.gov.au>, Anthony Mandic <no_sp.am_at_agd.nsw.gov.au> writes
>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.
>
  More context switching and hence cpu cache flushes...what about   multi-cpu machines. USer A on cpu 1, USer B on cpu 2?

>> > For a finely tuned application, row level locking
>> > does *not* matter.
>> Lock granularity is still a problem. Why do UNIX kernels lock
>> 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
 

-- 
David Williams