Re: Avoiding any locks in SQL Servers - read and understand....its magic.

From: Guido Stepken <stepken_at_little-idiot.de>
Date: Tue, 19 Aug 2003 08:06:32 +0200
Message-ID: <bhserr$26q$00$1@news.t-online.com>

Hi, Billy !

I don't really know, if PostgreSQL, Firebird, Informix, LogicSQL are phantasy products. The all support MVTO, MVCC. MS and other database makers haven't understood the great advantage of this technology. True, not implementing MBCC makes things much more simple for database programmers, but makes database programming much more expensive. Somehow this is wanted by MVP's, MSCD's, they earn more money.

Locking is not neccessary, database performance increases very much, because clients (and server) do not have to wait for any lock to be released.

If you still want to lock rows for many client access, make yourself clear, that you are programming with a technology, coming from stone age   of database programming. Live with it, waist money, believe, you're on the right way.

Say goodbye to locking, its not elementary for any business process. Look at traffic lights. All people think, they are neccessary. They're not. Substitute them by roundabouts and you will see, there will be much less traffic delays. Only the producers of traffic lights profit. By the way, this fact was proven in mathematical institute of cologne, germany by a former student, who worked on traffic simulations, never became really popular, Siemens was not delighted as producer from traffic lights technology.

regards, Guido Stepken

 >Billy Verreynne wrote:
> Guido Stepken <stepken_at_little-idiot.de> wrote i
>
>

>>There is a transaction manager, which keeps its eye on all timstamps of 
>>all inserts/updates and even on timestamps of transactions itself, to 
>>get all data reconstructed in the right way. 

>
> <snipped>
>
> This still sounds like fantasy to me. Worse, data needs to be
> "reconstructed". This smacks of unneeded complexity and probable data
> corruption when the reconstruction gets it knickers in a knot.
>
> The fact is that business processes do *not* work in parallel, but in
> serial. You cannot issue the invoice before the sale has happened. You
> cannot pay the claim before it is processed & evaluated. You cannnot
> evaluate it before it has been submitted.
>
> This means that locking the claim row, PREVENTING *any* access to it,
> is mandatory for each discreet processing step. It also means that
> each step needs the row's data as updated by the previous step.
>
> No amount timestamping and reconstruction can circumvent that.
>
> The biggest flaw in your argument is thinking that locking is bad. It
> is not. Please provide tangible evidance that locking in a OLTP system
> is bad.
>
> --
> Billy
Received on Tue Aug 19 2003 - 01:06:32 CDT