Re: Microsoft destroys TPC-C records!

In article <954938510.3922.0.nnrp-01.9e984b29_at_news.demon.co.uk>,   "Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote:
>
> Nuno,
>
> Read it through again - it is describing something
> that could happen in Oracle and requires application
> design to implement the business rule.
>
> The example is really saying:
> If you haven't a clue how to define
> and implement the business rules
> properly then its easier to code it
> wrong in Oracle.
>
> and pretending that this is a valid counter-argument
> Writers blocking readers is a bad idea.
>
> In Oracle, to ensure that only one withdrawal
> of $400 was made, both accounts would
> have to be locked for the duration of the
> transaction. This would have the same
> apparent effect, of course, as readers blocking
> writers - but under control of the application and
> done only when the business rule says that it
> is necessary.
>
> This one's a laugh of course:-
> The SQL Server database can also be set
> up to use the READ UNCOMMITTED ANSI
> standard transaction level, which shows
> account balance information even if the
> data has not been committed (Option 2
> above). In this case the teller sees -$100
> in the checking account, and informs the
> husband that there are insufficient funds,
> which also removes the chance of overdrawing
> funds.
>
> Just imagine the scenario -
> Husband asks for 100 dollars
> teller types in 400 dollars, and
> updates the record without commit.
>
> Wife asks for 400 dollars, gets told
> there are insufficient funds and
> hits the roof.
>
> In the meantime the husband says,
> 'No, I wanted £100' - by this time
> it's too late. the other teller has read
> the wrong uncommitted data and
> made the wife close the account.
>
> Again - this is a marketing pamphlet
> based on making something look like
> a benefit by quoting an example that
> looks nice superficially, but is actually
> an application design error.
>
> --
>
> Jonathan Lewis
> Yet another Oracle-related web site: http://www.jlcomp.demon.co.uk
>
> Nuno Souto wrote in message <38eb24f4.11792864_at_news-server>...
> >On 5 Apr 2000 01:59:17 GMT, Norris <jcheong_at_cooper.com.hk> wrote:
> >
> >>See the Locking differences between Oracle and SQLServer
> >>http://www.microsoft.com/sql/productinfo/transadvantage.htm
> >>
> >
> >OK, let's give it a try....
> >
> >
> >( - Provides higher accuracy with its "writer-blocks-reader"
> >behavior.)
> >
> >The example provided of the husband-wife is completely FALSE and
> >MISLEADING. It is NOT what ORACLE does.
> >
> >
>
>

Dont forget how this thread all started with the Million dollar challenge which is the same marketing hype. I havent read this article but from the replies it seems like a clear reply to the locking article that Oracle stated about SQL Server 6.5 comparing an Oracle locking strategy of holding the locks from the select and then updating then commiting when the user felt it was ok to do so. In SQL Server you cannot read the previous value without contention without using a dirty read. So basically the Oracle one was showing how using a dirty read in SQL Server would show incorrect values. In my opinion it is bad design to lock records like that. Pessimistic is the way to go which is implemented with timestamps in Sybase and SQL Server. I can see where supporting the idea of the previous value or skipping over them would be benificial in rare cases and is one of the key features Oracle has over SQL Server due to the rollback segment. If you must design your app that way then the clear choice is Oracle although as I said I think it is a mistake having a user comitting when he wants. Transactions in OLTP should be short. Look at all of the horror stories of DBA's having to whack processes in Oracle beacuse the user left their screen up. Sure a profile should be set up to have a proper timeout which would eliminate some of that but even 30 minutes of holding locks like that could interfere with some batch job that wants to update those records or possibly another user. Its wrong of both companies to write shit like this. There should just be a statement saying that Oracle can read the old value of a changed row where sql server cannot, it can just read the dirty value which is not good for any finicial related application. SQL Server does suopport row level locking but basically that only eliminates contention on inserts and updates when you have strictly increasing indexes. With proper design in Sybase and SQL Server before row level locking it was possible to eliminate almost all contention by using the appropriate indexes. Now you dont have to go out of your way as a DBA to design this although 6.5 had insert row level locking.

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Wed Apr 05 2000 - 00:00:00 CDT