Locking error (-107) with Dirty Read
In a situation where row level locking is in use and different records are being accessed in multiple sessions with Dirty Read, why is it possible to get a "record is locked" error?
-244: Could not do a physical-order read to fetch next row.
-107: ISAM error: record is locked.
If a row is selected with the intent to update, the update process acquires an update lock. Update locks permit other processes to read, or share , a row that is about to be updated, but they do not allow those processes to update or delete it. Just before the update occurs, the update process promotes the shared lock to an exclusive lock. An exclusive lock prevents other processes from reading or modifying the contents of the row until the lock is released.
An update process can acquire an update lock on a row or on a page that has a shared lock from another process, but you cannot promote the update lock from shared to exclusive (and the update cannot occur) until the other process releases its lock. If an attempt is made, the 244/107 error sequence will occur.
This is one possible cause for a -107 error. Please consider other possibilities if the transaction does not involve an update.
More support for:
Software version: 11.5, 11.7, 12.1
Operating system(s): AIX, Linux, OS X, Solaris, Windows
Software edition: Developer, Enterprise, Express, Growth, Hypervisor, Innovator, Ultimate, Workgroup
Reference #: 1646914
Modified date: 25 June 2014