This chapter contains the following topics:
JD Edwards EnterpriseOne does not implement any record-locking techniques. It relies on the native locking strategy of the vendor database management system.
In specific situations, the vendor database does not automatically lock as needed. In these situations, you can instruct JD Edwards EnterpriseOne to control record locking. For example, you can mandate record locking on the Next Numbers table to ensure the integrity of the Next Numbers feature.
You can lock JD Edwards EnterpriseOne records using one of the following methods:
Optimistic locking
Use optimistic locking (sometimes referred to as record change detection) to prevent a user from updating a record if it has changed between the time the user inquired on the record and the time user updates the record.
Pessimistic locking
Use pessimistic locking to prevent attempts to update the same record at the same time by different applications or users. The record is locked before it is updated.
You can set optimistic locking in the workstation jde.ini file. This type of database locking prevents a user from updating a record that changed since the user has inquired about it. If the record has changed, the user must select the record again and then make the change. This feature is available for business functions, table I/O, and Named Event Rules.
For example, assume that two users are working in the Address Book application The following table illustrates the optimistic locking process:
| Time | Action |
|---|---|
| 10:00 | User A selects Address Book record 1001 to inspect it. |
| 10:05 | User B selects Address Book record 1001 to inspect it.
Both users now have Address Book record 1001 open. |
| 10:10 | User B updates a field in Address Book record 1001 and clicks OK.
JD Edwards EnterpriseOne updates Address Book record 1001 with the information entered by User B. |
| 10:15 | User A updates a field in Address Book record 1001 and clicks OK.
JD Edwards EnterpriseOne does not update Address Book record 1001, and the system displays a message informing User A that the record has changed during the time that User A was viewing it. For User A to change the record, User A must re-select it and then update it. |
When the system detects that a record change has occurred, it displays a message indicating that the record has been changed since it was retrieved.
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.
You might need to use pessimistic locking in conjunction with transaction processing. For example, if you want the system to lock records between the read operation and the update, you must use pessimistic locking.
You might want to use pessimistic locking in a business function if the business function updates a table. The table being updated should have a high potential for record contention with another user or job. Remember that you should lock records for as short a time as possible. Ensure that the select or fetch for an update occurs as closely to the update as possible.