Re: deadlock

From: Thomas J Kyte <tkyte_at_us.oracle.com>
Date: 1996/03/22
Message-ID: <4it0t2$fce_at_inet-nntp-gw-1.us.oracle.com>#1/1

syoujit_at_tsi.co.jp (Pauro Tanaka) wrote:

>>> Oracle doesn't give up serializibility because it bases the "existence"
>>> of a transaction on timestamps.  So, "A user always sees a consistent
>>> view of all data, which consists of all data committed by other
>>> transactions as of that time and all changes made by the user up to
>>> that time."  See Ch. 10 of the Server Concepts Manual, again.  You 
>>> have to mess around if you want consistency at different times - 
>>> repeatable reads.  You're on your own if you start manually adjusting
>>> the default locking for transaction-level consistency.
 


>	I wrote that oracle gives up serializability.


>	But I mean that oracle gives up serializability in very high

>	transaction concurency cases.

>	Because Oracle has to lock table when you want to achieve 

>	serializability even if the index is defined on the column

>	where the retrieval condition is specified.

 


>	And even if you use read only transaction mode and Oracle refers


>	rollback segment, Oracle can't prevent phantom records.

 


>	Only way to achieve serializability in Oracle is


>	using S, or SRX or X lock mode to the table.

>	(if you specifies serializability to oracle, oracle always lock

>	table. )

Oracle 7.3 has added serializable transactions without table locks (or even shared read locks). Prevents phantom reads without using shared read locks on read information. Highest isolation possible with the highest degree of concurrency possible. Reads still don't block writes and writes still don't block reads.

Thomas Kyte
tkyte_at_us.oracle.com
Oracle Government

---

opinions and statements are mine and do not necessarily reflect the opinions of Oracle Corporation. Received on Fri Mar 22 1996 - 00:00:00 CET