The ORDA series continues! In this blog post, we’ll look at how you can use locks in your databases with ORDA concepts! It’s not uncommon to need to manage conflicts that might occur when several users or processes load and/or attempt to modify the same records at the same time. Record locking is a methodology used in relational databases to avoid inconsistent updates to data.

ORDA provides an optimistic locking mode in addition to the one you already know (pessimistic locking).

Example: how to use pessimistic locking with ORDA

Different locking modes

RECORDs AND ENTITies

Just as a reminder, a record is the physical record in the database which is accessed through an entity. An entity is a reference on a record (see Entity section in the glossary). Records are locked and unlocked through entities.

Optimistic locking

In optimistic locking, a record is checked before it’s saved to see if other processes have modified it since you loaded it in an entity. The benefit is that the record is locked only during the save method.

Optimistic locking relies on the stamp of the records. Each record has an internal stamp that is automatically incremented every time the record is saved in the database. If a record has been updated since you loaded an entity, the save(), drop(), and lock() methods will return a specific status code indicating that the stamp has changed. You’ll then have to decide what to do to handle this conflict.

By default, ORDA works with optimistic locking, but pessimistic locking is also available.

EXAMPLE

C_OBJECT($employee;$statusSave)
 
// Get the first employee whose last name is "Wates"
$employee:=ds.Employee.query("lastName=:1";"Wates").first()
 
If ($employee#Null)
 // Set name to "Mac Arthur" 
 $employee.lastName:="Mac Arthur"
 // Save employee 
 $statusSave:=$employee.save()
// Test if the save is successful
 If ($statusSave.success)
  ALERT("Successfully saved!")
 End if
End if
// The record in the database has been updated

I’m sure you’re eager to learn more about optimistic locking. Another blog post, fully dedicated to this concept, is coming soon. Stay tuned!

Pessimistic locking

In pessimistic locking mode, records are locked when being read so other processes can’t update them. This ensures that a modified record can be written at the expense of locking records to other users. The record is locked even when there is no concurrent access.

With pessimistic locking, you must lock records before updating them and unlock them after the update. As long as a record is locked, saving / dropping / locking the record in other processes will fail until it is unlocked by the process that locked it.

To lock an entity, use the lock() method and the unlock() method to unlock it.

The “classic” 4D uses pessimistic locking.

EXAMPLE

C_OBJECT($employee;$statusLock;$statusSave;$statusUnLock)
 
// Get the first employee whose last name is "Wates"
$employee:=ds.Employee.query("lastName=:1";"Wates").first() 
 
If ($employee#Null)
  $statusLock:=$employee.lock() // Lock the entity
  // The entity has been successfully locked
  If ($statusLock.success)
    $employee.lastName:="Mac Arthur" // Set name to "Mac Arthur"
    // Save employee-No need to check the status because the entity is locked
    $statusSave:=$employee.save()
    // Unlock entity, so other processes will be able to save/drop/lock it
    $statusUnLock:=$employee.unlock()
  End if
End if
// The record in the database has been updated


Don’t be afraid of forgetting to unlock a record, ORDA will automatically unlock it if there are no more references on the entity that locked it.