Bloqueo de entidades con ORDA

Traducido automáticamente de Deepl

¡La serie ORDA continúa! En esta entrada del blog, veremos cómo puedes usar bloqueos en tus bases de datos con conceptos ORDA. No es raro necesitar manejar los conflictos que pueden ocurrir cuando varios usuarios o procesos cargan y/o intentan modificar los mismos registros al mismo tiempo. El bloqueo de registros es una metodología utilizada en las bases de datos relacionales para evitar actualizaciones inconsistentes de los datos.

ORDA proporciona un modo de bloqueo optimista además del que ya conoces (bloqueo pesimista).

Ejemplo: cómo utilizar el bloqueo pesimista con ORDA

Different locking modes

REGISTROS Y ENTIDADES

Como recordatorio, un registro es el registro físico de la base de datos al que se accede a través de una entidad. Una entidad es una referencia a un registro (ver la sección de Entidades en el glosario). Los registros se bloquean y desbloquean a través de las entidades.

Bloqueo optimista

En el bloqueo optimista, se comprueba un registro antes de guardarlo para ver si otros procesos lo han modificado desde que se cargó en una entidad. La ventaja es que el registro se bloquea sólo durante el método de guardado.

El bloqueo optimista se basa en el sello de los registros. Cada registro tiene un sello interno que se incrementa automáticamente cada vez que el registro se guarda en la base de datos. Si un registro ha sido actualizado desde que se cargó una entidad, los métodos save (), drop() y lock() devolverán un código de estado específico indicando que el sello ha cambiado. Entonces tendrás que decidir qué hacer para manejar este conflicto.

Por defecto, ORDA trabaja con bloqueo optimista, pero también está disponible el bloqueo pesimista .

EJEMPLO

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"
// Guardar el empleado
$statusSave :=$employee.save()
// Test if the save is successful
If ($statusSave.success)
ALERT ("¡Guardado con éxito!")
End if
End if
// El registro en la base de datos ha sido actualizado

Seguro que estás deseando saber más sobre el bloqueo optimista. Pronto habrá otra entrada en el blog, dedicada por completo a este concepto. Esté atento.

Pessimistic locking

En el modo de bloqueo pesimista, los registros se bloquean cuando se leen para que otros procesos no puedan actualizarlos. Esto asegura que un registro modificado pueda ser escrito a expensas de bloquear los registros a otros usuarios. El registro se bloquea incluso cuando no hay acceso concurrente.

Con el bloqueo pesimista, hay que bloquear los registros antes de actualizarlos y desbloquearlos después de la actualización. Mientras un registro esté bloqueado, guardar / soltar / bloquear el registro en otros procesos fallará hasta que sea desbloqueado por el proceso que lo bloqueó.

Para bloquear una entidad, utilice el método lock() y el método unlock() para desbloquearla.

El 4D «clásico» utiliza el bloqueo pesimista.

EJEMPLO

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

No tengasmiedo de olvidarte de desbloquear un registro, ORDA lo desbloqueará automáticamente si no hay más referencias en la entidad que lo bloqueó.

Avatar
• Propietario de producto - Marie-Sophie Landrieu-Yvert ingresó al equipo de 4D Product como Propietario de producto en 2017. Como tal, está a cargo de escribir las historias de los usuarios y luego traducirlas en especificaciones funcionales. Su papel es también asegurarse de que la implementación de la funcionalidad entregada cumpla con las necesidades del cliente. Marie-Sophie se graduó en la Escuela de Ingeniería de ESIGELEC y comenzó su carrera como ingeniera en IBM en 1995. Participó en varios proyectos (de mantenimiento y creación) y trabajó como desarrolladora de Cobol. Luego trabajó como diseñadora de UML y desarrolladora de Java. Sus principales funciones fueron analizar y redactar requisitos funcionales, coordinar los equipos de negocio y de desarrollo.