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

In article <3484D89D.334_at_agd.nsw.gov.au>, Anthony Mandic <no_sp.am_at_agd.nsw.gov.au> writes
>David Williams wrote:
>>
>> Anthony Mandic writes:
>>
>> > 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?
>
> Ah, I've been waiting for you to being this up. There
> is only one resource involved - the lock table/memory.
> A spinlock is created by the first one to get in and
> grab it. Oh, and its not so much the number of CPUs
  Psst! One spinlock on the whole lock table. Thats like UNIX with one spinlock on the file management portion of the OS! You should have one spinlock per file region.

   Remember a lock table has a hash table above it. Imag8ine the lock table like an array. You have one spinlock per lock table entry. Rows hash to an entry and you take the spinlock on that entry.

> but the number of database server engines on CPUs.
>
> There is always something along the line where it
> resolves down to one resource. Adding engines increases
> concurrency which increases the likelihood of deadlocks.
>
>-am
 

-- 
David Williams