Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: Avoiding any locks in SQL Servers - read and understand....itsmagic.

Re: Avoiding any locks in SQL Servers - read and understand....itsmagic.

From: Noons <wizofoz2k_at_yahoo.com.au>
Date: 1 Sep 2003 14:20:35 -0700
Message-ID: <73e20c6c.0309011320.6322cac1@posting.google.com>


Guido Stepken <g.stepken_at_t-online.de> wrote in message news:<3F5375D2.3060200_at_t-online.de>...

> Read Concurrency). No two transactions can write into the same row at
> the same time, but one can read and one can write.

No. Most definitely not. Repeat after me: WITH DEFAULT ORACLE LOCKING, A READER IS NEVER, NEVER, NEVER, NEVER, NEVER, NEVER, NEVER, NEVER, NEVER, NEVER, NEVER, NEVER, NEVER BLOCKED BY A WRITER OR ANY OTHER READER. Just in case you didn't get it:
WITH DEFAULT ORACLE LOCKING, A READER IS NEVER, NEVER, NEVER, NEVER, NEVER, NEVER, NEVER, NEVER, NEVER, NEVER, NEVER, NEVER, NEVER BLOCKED BY A WRITER OR ANY OTHER READER. Got it now? Your phrase above should read: "but *many* can read and one write".

> To avoid deadlocks, transactions are simply dropped. So, any writing
> transaction into postgresql should be read again.

That will come in useful for updating bank accounts: "transactions are simply dropped"?

Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam Received on Mon Sep 01 2003 - 16:20:35 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US