Consultor Eletrônico

Record locks are not released inside a transaction

900912-SLK01Here is some information regarding how PROGRESS handles record locks
when the record is scoped higher than the transaction, and you re-find
that record with no-lock, and then again with an exclusive-lock within
the transaction block.

Here is the program:

def var i as integer.
find first customer no-lock.
repeat i = 1 to 3:
find first customer no-lock.
if i = 1 then find first customer exclusive-lock.
unix value("mpro demo -p lockck.p").
end.
where lockck.p is a program that displays the lock-status for the
first customer. During the 3 iteration of the repeat block, the
lock is exclusive-lock, shared-lock and no-lock.
Why does the customer have shared-lock during the second iteration?

Here is how Development explained the lock status:

1. find first no-lock (proc block):
client: no-lock; broker: no-lock
find first no-lock (repeat block - also the transaction):
client: no-lock; broker: no-lock
find first excl (repeat block) - client: excl; broker: excl
end of transaction: client: share; broker: excl (record scoped
higher than transaction).
2nd iteration of repeat (another transaction):
find first no-lock: client: no-lock; broker: shared limo lock
(can't release cause still inside a transaction).
end of transaction: client: no-lock; broker: no-lock (all
limbo locks discarded at the end of the transaction).
3rd iteration of repeat (another transction):
find first no-lock: client: no-lock; broker: no-lock

Some additional comments from Development:

Subject: Re: Find first and locking
On a WHERE clause that contains an RANGE MATCH (see lang. ref p.230)
the server returns the range of records. It does not perform a
"Release lock, and get next candidate" to keep the number of locks
down. Outside a transaction, the client sends the server a signal
get the server to release the locks once the client has found its
target record.

That is exactly what Progress does, but the rule is,
if a lock is released during a transaction, it remains
in effect until the end of the transaction.

The good news is that this problem is supposed to go away with
version 7 as the server will be able to completely resolve the
request and only pass back the target record.

This is correct. The rule about locks lasting until the end of
a transction is still valid, but does not apply to records which
the server never returns back to the client. In self-service
multi-user, there is no server, so the client does all the work.
Nevertheless, it will still have the same lock behavior as the
client/server situation.

Progress Software Technical Support Note # 5927