VC wrote:
> Hi:
>
> "Serge Rielau" <srielau_at_ca.ibm.com> wrote in message
> news:36ucs9F575gaaU1_at_individual.net...
>
>>VC wrote:
>>
>>>"Serge Rielau" <srielau_at_ca.ibm.com> wrote in message
>>>news:36qshqF564is0U1_at_individual.net...
>>>...
>>>
>>>
>>>>Isn't it ironic that if SQL Server 2005 ever ships it will be the only
>>>>mainstream DBMS supporting all major isolation levels?
>>>
>>>
>>>...
>>>
>>>What exactly do you mean by the above ? What are "major isolation
>>>levels" ? IBMS's DB2, among others, supports all the *standard*
>>>isolation levels while Oracle does not.
>>
>>If I'm not mistaken SQL Server falls under "among others". In addition SQL
>>Server 2005 allegedly supports multi versioning.
>
>
>
> You are confusing isolation levels with concurrency control. There are,
> roughly speaking, two approaches to concurrency control: locking (DB2/SQL
> Server/Sybase) and multiversioning (Oracle/Firebird/Postgress). Each of the
> two can implement various isolation levels that improve concurrency at the
> expense of creating various anomalies. E.g. Sybase (as well as DB2 or SQL
> Server) implements SERIALIZABLE, REPEATABLE READ, READ COMMITTED, READ
> UNCOMMITTED with SERIALIZABLE ensuring correct behaviour but allowing the
> least concurrency. Oracle has SNAPSHOT (mis-named SERIALIZABLE) and READ
> COMMITTED. Oracle also has the READ ONLY isolation level , but it's really
> just a subset of SNAPSHOT.
>
> There are hybrid schedulers (locking+MVCC), such as MySQL InnoDB and SQL
> Server 2005. The latter implements MVCC and, thanks to that, has Oracle
> style SNAPSHOT isolation level.
>
> VC
Hmm, I may have used sloppy language. It apears there is a difference of
opinion on what READ COMMITTED means, but I couldn't google my way
quickly to a formal definition... It apears DB2 docs believe READ
COMMITTED is matches by DB2's CURSOR STABILITY. That is definitely not
what Oracle does. But since my head hurts thinking more deeply about
this I fold. :-)
Cheers
Serge
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab
Received on Wed Feb 09 2005 - 19:26:13 CST
