Re: Row locking and serializability

> There is a 'work around' If you look you the SERIALIS(Z?)ABLE
> init.ora parameter, and set this to TRUE, then Oracle
> reverts to version 5 behaviour I think, and as with RDB
> you would not be able to insert the second row.
>
> This plays merry hell with performance, though.

From the Oracle 8.1.5 "README" ...

1.7 SERIALIZABLE=TRUE

The init.ora parameter SERIALIZABLE=TRUE is no longer supported in Oracle8 and beyond. The default behavior henceforth is as if SERIALIZABLE was set to FALSE. Use the SET TRANSACTION ISOLATION LEVEL SERIALIZABLE command to Achieve similar transaction isolation behavior.

> Of course, this failing in proper serialisability is a
> consequence of the massive performance advantage
> you get from Oracle's ability to keep readers and writers
> from blocking each other, but it does mean you have
> to relay on other mechanisms (e.g. integrity constraints)
> to avoid the side-effects of errors due to the example
> you quote.

Don't integrity constraints act simply as extensions of your application program and hence become subject to the Oracle concurrency model, profiting from its strengths and constrained by its weaknesses?

Disclaimers: (1) My employer may have opinions very different from mine. (2) My opinions may prove to be significantly incorrect. (3) Oracle itself is the final authority on the capabilities on the Oracle product line.

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't. Received on Mon Jul 05 1999 - 20:46:25 CDT