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

Maybe I missed something, and I admit that I don't know that much about MVTO. But when you modify data with MVTO, aren't you simply creating *new* data? You aren't modifying *old* data. Instead, you are creating a new version of the old data. Versioning uses different techniques than the techniques required for maintaining transaction consistency in non-versioned data. IMO, you can't use versioning and then say that locks are not necessary. They may not be necessary in versioned data, but they are necessary in non-versioned data if you want to maintain any semblance of transaction control and consistency.

Cheers,
Brian

Guido Stepken wrote:
>
> Hello, Billy !
>
> 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. With MVCC and MVTO it is
> possible to delay one transaction as long, as the other transaction
> writing into the database. 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.
> Its a very clever trick to time - shift two simulaneous writing events
> on the same data set, in order to avoid any collision.
>
> I am sorry for you, that even you still think, locks are necessary. They
> aren't, neither from practical, nor from theoretical point of view.
>
> Read my postings about MVTO in goolge groups.
>
> tnx for reading and understanding Reed's mechanism.
>
> regards, Guido Stepken
>
> >Billy Verreynne wrote:
>
> > Are you now saying that two people can change the same rows at the
> > same time in PostgreSQL without locking out one another and without
> > one transaction overwriting the other's changes?
> >
> >

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

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"