Re: Lock requests queued?

From: Mark D Powell <>
Date: Wed, 20 Jun 2012 07:51:26 -0700 (PDT)
Message-ID: <>

On Tuesday, June 19, 2012 7:05:54 PM UTC-4, joel garry wrote:
> On Jun 19, 10:10am, Frank Langelage <> wrote:
> > To serialize some kind of data modifications our application uses an
> > exclusive table lock (lock table %s in exclusive mode).
> > The process retrieves some data, then acquires the lock and does the
> > modifications. Then work is committed and with that the lock is released.
> > After process 1 has acquired the lock at time t1, other processes might
> > come and require the lock. Lets say process 2 at t2 and process 3 at t3.
> > Is it guaranteed, that the process 2 will be the next to get the lock
> > because it was first who tried to get it, so waiting for the longest
> > time? Or maybe better: are the lock requests queued?
> > Or is it more or less random, depending which of the Oracle
> > processes/threads gets CPU time?
> >
> > (Oracle server version 10.2 or 11.2 on Windows, IBM AIX and Solaris SPARC).
> I'm not real sure, but I think it will be random. I believe if you are
> overriding the default locking, you are responsible for making it do
> what you want. Oracle uses lock escalation, so you really have to
> watch what is happening. There are various examples around on how to
> check what locks are happening, the first thing I googled upon was
> this (note the TM discussions):
> And of course,
> jg
> --
> is bogus.
> Im absolutely personally responsible, Jamie Dimon told the Senate
> Banking Committee in Washington, D.C.
> So now "personal responsibility" means "make others pay."

"Oracle uses lock escalation" Since when? In SQL Server if you take too many row locks in a block SQL Server will upgrade the row locks to a page lock and if you get too many page locks in the table the page locks are upgraded to a table lock, but Oracle does not do this. In fact the modern versions of SQL Server pretty avoid doing this.

HTH -- Mark D Powell -- Received on Wed Jun 20 2012 - 09:51:26 CDT

Original text of this message