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

Hello, Niall !

1. PostgreSQL high volume servers installations are uncountable. We have several servers running 24*7.
2. Benchmarks i have never tried (see logicsql, which has shown 30-50% advantage over oracle in special tests. PCMAG has shown, that MS SQL Server 2000 is crap, i give a shit, but i know exactly, when SQL Server is poor performing)
3. Technical Support is not neccessary. Throw away all code in your application, which has to do with locking....;-)) You will not loose any update, no fear. Developments for PostgreSQL, Firebird, Informix, Oracle, LogicSQL planned ? How many huge software companies got bankrupt ? Can you imagine, Linux disappears suddenly ?
4. You still think, that locks are needed to prevent mistakes on parallel access. Ok, continue to think so, developing with stone age software, expensive, very complicated to program. I prefer freeware, easy to program. What do you think, who will survive ? M$ programmers ?

You should try to eat shit, billion flies cannot error. (sorry, i couldn't resist)

regards, Guido Stepken

Niall Litchfield wrote:

> 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?
>
>
Received on Tue Aug 19 2003 - 06:08:36 CDT