Kbase P21132: Dummy lock conflict due to Get-lock not using a word-index
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
6/18/2003 |
|
Status: Unverified
FACT(s) (Environment):
Progress 9.1x
SYMPTOM(s):
Locked records are out of the result set.
Locked records are not compliant with the entire query WHERE clause.
Problem happens in a client server environment.
Not using word-index.
<file-name> in use by <user> on <tty>. Wait or choose CANCEL to stop. (2624)
CAUSE:
The database engine must lock a record before fetching it. These are called record get locks and are generally short-lived locks. To understand why, imagine that a record is fragmented across several database blocks. When you fetch a record, the database engine has to piece together the complete record before it gives it to the 4GL. This lock (called a record get lock) prevents any other user from modifying or deleting that record while the engine is piecing it together for a fetch.
FIX:
When this situation happens, then the developers should use a different index for the WHERE clause or use optimistic locking techniques: First fetch in no-lock mode, then upgrade the lock with a FIND CURRENT EXCLUSIVE before updating the record. In a FOR EACH loop, a second buffer will be required to do a FIND Buffer2 EXCLUSIVE WHERE ROWID(buffer2) = ROWID(MyTable). Keep in mind that this solution is bad for performance, but it is the only possible one when records are locked for a long time (pure client server), which is not the case in a distributed application with ADM2.