Pessimistic Locking

Pessimistic locking is sometimes referred to as record locking. You can use pessimistic locking to prevent multiple users or applications from updating the same record at the same time. For example, suppose a user enters a transaction that uses Next Numbers. When the user clicks OK, the Next Numbers feature selects the appropriate Next Numbers record, verifies that this number is not already in the transaction file, and then updates the Next Numbers record by incrementing the number. If another process tries to access the same Next Numbers record before the first process has successfully updated the record, the Next Numbers function waits until the record is unlocked and then completes the second process.

Pessimistic locking in JD Edwards EnterpriseOne is implemented by calling published JDEBase APIs. When you use pessimistic locking, you should consider the time required to select and update a record because the record is locked until the update is complete. Transaction processing uses a special set of locking APIs. A locked record might or might not be part of a transaction. Record locking APIs are independent of the transaction and its boundaries. They always lock, regardless of whether you are in manual or auto commit mode.

Records that are updated using pessimistic locking APIs (such as JDB_FetchForUpdate or JDB_UpdateCurrent) within a transaction boundary are locked from the time the record is selected for update until the commit or rollback occurs. Records within the transaction boundary that are updated without using pessimistic locking APIs are locked from the time of the update until the commit or rollback occurs. This is also true if you use a business function to define and activate transaction processing.