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

"Christopher Browne" <cbbrowne_at_acm.org> wrote in message news:bi849b$6cpds$1_at_ID-125932.news.uni-berlin.de...

> > 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.

And this is all supposed to happen without any overhead whatsoever? Like magic, I suppose...

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

and still with all these explanations, we cannot find a concrete example of how a bank account gets concurrently updated without blowing the balance...

> >
> > 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.

and here it gets repeated ad-nauseum. Dunno about every1 else, but the line of argumentation is sounding awfully troll-ish. I'd let him dream...

>
> Surprise, surprise, the row can and will be locked so that those
> concurrent transactions will all execute serially.

Well either that or something is really wrong with Einstein and that time thing of his...

--
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam