Re: Oracle threatens to sue Standish over an article

In article <CAML7E.6uD_at_feanor.xel.com>, shaw_at_feanor.xel.com (Greg Shaw) writes:
|>
|> As I understand it (and correct me if I am wrong), discrete transactions
|> require that each transaction is unique in the database. e.g. you are
|> assured that there is not an update occuring on one record in the database
|> by two transactions. This means that database locking (record and/or
|> table) isn't necessary. This is what I contend is not an accurate test for
|> a 'real world' database system. Generally, when going hundreds of
|> transactions per second, that is doing updates AS WELL AS additions.

This is not correct! Discrete transactions does NOT require that each transaction is unique in the database! It fully satisfy the ACID rules and provides a high degree of concurrency (less sensitive to hot-spots).

As I understand it discrete transactions employs a mechanism similar to IMS/FastPath's field calls. Field calls does not require locks on the records before the transaction is committed. During commit processing the records are locked, checked and updated. For info on discrete transaction contact Oracle and I am shure they will correct your "little" misunderstanding.

One funny observation is that IBM implemented field calls in 1976, almost 10 years before the publication of the DebitCredit benchmark (1985) which eventually became TPC-A and TPC-B in respectively 1989 and 1990. There are no way that field calls was made with the benchmark in mind, but rather that someone needed it. But what happens when Oracle implements it...... ?

Btw. my defense for Oracle here is not because I am affiliated with Oracle in any way (I have even not used it) but rather I am a bit annoyed (understatement) with people thinking that *their* application is the average application and that benchmarks should reflect their application only. TPC-A and TPC-B are benchmarks for high intensity transaction systems with at least 10 (maybe 100) concurrent users issuing light transactions (touching less than 10 records), eg. banking, seat reservation, telecom. In many respects relational DBMS' have lagged far behind network/hierachical systems (eg. IMS) which have ruled this market. I think Tandem was the first company that was able to compete using a relational system (NonStop SQL). A few days ago I saw an announcement for the Tandem NonStop Himalaya server which scales up to 10,000 TPS. Now it looks like Oracle is going for this market too and don't blame them for it. Instead be a bit more critically in the way you use the benchmark results and compare apples with apples.

-- 
Oystein Torbjornsen                           Phone: +47 7 597057 (office)
Division of Computer Systems and Telematics          +47 7 529291 (home)
Norwegian Institute of Technology             Email: oytor_at_hobbes.er.sintef.no
N-7034 Trondheim, Norway                         or  oystein_at_idt.unit.no