Re: Wait for lock?

I'm afraid there are several misconceptions in this discussion.

1. When locks are made on row level, table lock contention cannot possibly exist. Unless lots of users are trying to update the same record, but it's an application design problem.
2. Isolation level read dirty doesn't apply here. Oracle never lock for read, neither it waits for locked rows when reading. So it will read all commited data from the table even when the whole table locked exclusive.
3. For interactive applications you always need immediate responce, so you need lock nowait. For batches you'd prefer application to wait for a lock. I don't see any need for lock timeout. Unless you think that you need lock for consistent read, but it's not the case in Oracle. Oracle NEVER locks when reading.

In article
<A3D4FED550018CB5.B318B10D7607976E.F30CC76EE892BEF0_at_lp.airnews.net>,   dan wright <dw420_at_nospammepleezeairmail.net> wrote:
> Interesting that I got a much greater response from the Informix
> newsfroup about using Oracle after heavy use of Informix than I did
 from
> the Oracle newsfroup.
>
> Anyway - apparently Oracle has no equivalent to Informix's ability to
> specify a timeout period when waiting for a lock.
>
> Is this correct? You can either tell Oracle to wait forever, or to
 not
> wait at all.
>
> So, if I expect the possibility of contention on a database table, but
> setting isolation to dirty read is not an option, I can't tell Oracle
 to
> keep trying for a few seconds?
>
> So, what in Informix would be a simple "SET LOCK MODE TO WAIT 5" would
> be implemented by trapping lock exceptions and retrying several times
> before giving up. What a pain....
>
> And another thing - just what is the ANSI standard for an outer join?
 I
> thought both Informix and Oracle were ANSI-compliant, but the syntax
 for
> outer joins doesn't seem similar at all (At least in Informix it's
> simple and obvious).....
> (Incidentally Sybase has a really screwed up syntax for outer joins as
> well)
>
> Thanks for any input
>
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Mon Sep 18 2000 - 13:03:17 CDT