Re: Usage of RowId...

From: Nuno Guerreiro <nuno-v-guerreiro_at_telecom.pt>
Date: 1998/04/15
Message-ID: <35348f0d.5516251_at_news.telecom.pt>#1/1


On Sat, 11 Apr 1998 09:16:48 -0400, "Brian K. Lawton" <NOSPAM.Lawton_at_RDAConsultants.Com> wrote:

>If I'm trying to implement optimistic concurrency within my database, is the
>RowId attribute the correct place to be checking? If not, what is Oracle's
>equivalent to SQL Server's timestamp datatype?
>
>________________________________________________
>Brian K. Lawton (mailto:Lawton_at_RDAConsultants.com)
>RDA Consultants Limited (http://www.RDAConsultants.com)
>
>
>

You should describe your problem more precisely. I'll try answering your question, anyway.

By default, Oracle statement-level read consistency, i.e., when any SQL statement is issued (SELECT, DELETE, UPDATE, INSERT), it is guaranteed that it will operate or select the records that existed on a table at the exact time the statement was issued.

There are some situations in which you may need transaction-level read consistency, i.e., if you issue a e.g. a SELECT statement several times during your transaction, the result set should always be the same, even if there are other transactions performing UPDATE, DELETE, etc. on the table. By default, Oracle doesn't provide this level of consistency.

If by 'optimistic' concurrency you mean 'extremely secure' concurrency, then you may force Oracle to provide transaction-level read consistency for every transaction in every session. You should issue the following statement at the beginning of each database session:

ALTER SESSION SET ISOLATION_LEVEL SERIALIZABLE; If you want to enable this level of isolation for only one transaction, then issue the following command at the beginning of the transaction:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; The effect of issuing these commands is that you'll get a database environment in which several transactions change or read the database and although their executions are overlapped, it is exactly as if they were executed one after the other.

These are the standard ways of doing things in Oracle - I wouldn't try ANY alternative method involving timestamps, since you'll be reinventing the wheel. These commands enable you to control everything you'll ever need in order to have a consistent view of the database throughout any transaction.

The 'Oracle 7 Server Concepts' manual, chapter 10 - Data Concurrency provides a detailed description of how Oracle implements data concurrency.

Good Luck,

Nuno Guerreiro Received on Wed Apr 15 1998 - 00:00:00 CEST

Original text of this message