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

Guido Stepken wrote:

> Yes, Billy, there is a solution for avoiding locks of any sort. A SQL
> Server can be programmed lock free, even if you do not unterstand the
> very clever idea of MVTO (multi versioning timestamp odering), as i
> pointed out in several postings. In MVTO all datasets have timestamp as
> well as the transaction manager itself.

As I said.. technical wet dreams and SQL fantasies...

> Then, if done, the delayed transaction
> recapitulates, what should have been done and updates the data in this
> way, as if a lock had been set for avoiding collisions.

Client software uses column B to determine the value of column C before changing the value of B (same row) in table T when business rule X.

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