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

"Guido Stepken" <stepken_at_little-idiot.de> wrote in message news:bhserr$26q$00$1_at_news.t-online.com...
> Hi, Billy !
>
> I don't really know, if PostgreSQL, Firebird, Informix, LogicSQL are
> phantasy products. The all support MVTO, MVCC. MS and other database
> makers haven't understood the great advantage of this technology.

Can you demonstrate one business critical high-volume system running, not merely on the RDBMS products you describe, but written entirely with this MVTO model? Or since you quote benchmarks perhaps a TPC benchmark. SQL Server,Oracle etc can demonstrate this many times over, as to some extent can the systems that you quote when programmed traditionally.

Where is the technical support for the technology so that when I put in a support call claiming that I have lost an update you can show me how this didn't happen. What developments are planned over the next 3 years? You know all the usual business reasons for buying a product.

Technically, I don't see that you have addressed this issue which others have raised.

time t0 tx1 selects name,address line1,address line 2,zip code from an address table for supplier id 1;
time t0+1 tx2 selects name,address line1,address line 2,zip code from an address table for supplier id 1;
time t0+2 tx1 updates name to the name of the correct supplier at that address.
time t0+3 tx2 updates the address to the correct address of the supplier for the name that existed at t0+1
time t1 tx and tx2 both commit. By removing the row locking mechanism you have managed to create an app that allows bad data to be corrected in two opposite ways by two different keyboard operators. Which transaction does the new transaction manager rollback?

-- 
Niall Litchfield
Oracle DBA
Audit Commission UK




> True,

> not implementing MBCC makes things much more simple for database

> programmers, but makes database programming much more expensive. Somehow

> this is wanted by MVP's, MSCD's, they earn more money.

>

> Locking is not neccessary, database performance increases very much,

> because clients (and server) do not have to wait for any lock to be

> released.

>

> If you still want to lock rows for many client access, make yourself

> clear, that you are programming with a technology, coming from stone age

>   of database programming. Live with it, waist money, believe, you're on

> the right way.

>

> Say goodbye to locking, its not elementary for any business process.

> Look at traffic lights. All people think, they are neccessary. They're

> not. Substitute them by roundabouts and you will see, there will be much

> less traffic delays. Only the producers of traffic lights profit. By the

> way, this fact was proven in mathematical institute of cologne, germany

> by a former student, who worked on traffic simulations, never became

> really popular, Siemens was not delighted as producer from traffic

> lights technology.

>

> regards, Guido Stepken

>

>  >Billy Verreynne wrote:

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

>