>Robert Treat
> On Sunday 15 February 2004 16:36, Tom Lane wrote:
> > Anthony Rich <richae@optusnet.com.au> writes:
> > > When one process has a "row lock" on one or more rows
> > > in a table, using "SELECT...FOR UPDATE" in default lock
> > > mode, another process has NO WAY of aborting from the
> > > same request, and reporting to the user that this record
> > > is already locked, reserved, or whatever you want to call it.
> >
> > Not so. See the statement_timeout parameter.
> >
>
>what is
> needed
> i think is a lock_timeout, which times out soley for cases where the
lock
> can
> not be aquired in a speedy manner.
Perhaps another way is to specify that you do not wish to wait at all.
Oracle and DB2, possibly others, allow the use of the NOWAIT operator,
applied to a preceding LOCK statement, which acts just as it says. If it
encounters a lock, it returns immediately. This then returns control
immediately to the application, so that it can report to the user to get
further instructions. My understanding is that implementing that might
require some fairly basic changes to the internal locking API - maybe
not too complex, but it might cause many changes; I'd vote for it, but
don't hold your breath...
Alternatively, don't use the SELECT..FOR UPDATE metaphor, try another
design that doesn't require this style of locking. Application level
locking can get you round many problems - the database can't do
everything.
Best regards, Simon Riggs
