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

In article <34838DAD.7845@agd.nsw.gov.au>, Anthony Mandic <no_sp.am@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