Robert Treat
needed
i think is a lock_timeout, which times out soley for cases where the lock
can
not be aquired in a speedy manner.
On Sunday 15 February 2004 16:36, Tom Lane wrote:
Anthony Rich <richae@optusnet.com.au> writes:
what isAnthony 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.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.
needed
i think is a lock_timeout, which times out soley for cases where the lock
can
not be aquired in a speedy manner.
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