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

> No, you do not create new data. You time - shift all transaction, let
> them run, as if they are working alone (in reality they work on their
> own snapshot of database, thank MVCC) and then, before updating the
> database, you look at the timestamp of other transactions and at the
> timestamp of updates and rearrange all, as if a lock had been set.
> Afterwards, you can drop all changes on the snapshot, a clean up.
> There is some overhead, yes. But that equals by many times the blocks in
> SQL Server, caused by locks, blocking each other (no deadlocks).

"Some" overhead is probably being way too lenient in this scheme, especially in a highly concurrent environment where hundreds or thousands of users are attempting to modify the same data. So if there are no locks, and User A reads data, User B updates the same data, and then User A goes to update the same data depending on what User A read originally, how is the whole thing syncronized? Does User B look at User A's timestamp (even though User A has yet to modify data)? What happens to User A's transaction. User B modified the data, does User A then get killed?

Cheers,
Brian

-- 
===================================================================

Brian Peasland
dba_at_remove_spam.peasland.com

Remove the "remove_spam." from the email address to email me.


"I can give it to you cheap, quick, and good. Now pick two out of
 the three"