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

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