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 01:11:44 +0200
Message-ID: <bhrmi4$f0m$05$1@news.t-online.com>

Hi Billy !

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. In SQL Server you can roll back and forward all transactions, right ? Same does MVTO manager. In merge replication you have a merge controller, who takes care, that all data from all slaves are synchronized correctly into the master, correct ? Don't forget that we have versions. Without MVCC and additional columns with timestamps, it doesn't work. Same in SQL Server and ACCESS (Master-Slave replication). Without hidden columns, it doesn't work. MVTO is much more advanced, than merge replication...

regards, Guido Stepken

 >Billy Verreynne wrote:
> Time 01+00. User 1 locks row 1 in table T to perform his update by
> applying business rule X.
>
> Time 01+01. User 2 locks row 1 in table T to perform his update by
> applying business rule X.
>
> Time 01+FUBAR. What value does column C now contain?
>
> Or is the Lock Manager prescient? Don't tell me, you're calling it Maud'ib?
>

>> Its a very clever trick to time - shift two simulaneous writing events 
>> on the same data set, in order to avoid any collision.

>
>
> And I can prove to you with Feynmann diagrams and moving around positive
> and negative signs that a photon can move backwards into time in order
> to create the electron that created that photon in future time.
>
> Wonderous tricks we can play... what works in practise is of course
> another matter all together.
>
> --
> Billy
>
Received on Mon Aug 18 2003 - 18:11:44 CDT