Bloccare le entità con ORDA

Tradotto automaticamente da Deepl

La serie ORDA continua! In questo post vedremo come utilizzare i lock nei database con i concetti ORDA! Non è raro dover gestire i conflitti che possono verificarsi quando diversi utenti o processi caricano e/o tentano di modificare gli stessi record nello stesso momento. Il record locking è una metodologia utilizzata nei database relazionali per evitare aggiornamenti incoerenti dei dati.

ORDA offre una modalità di blocco ottimistica oltre a quella già nota (blocco pessimistico).

Esempio: come usare il locking pessimistico con ORDA

Different locking modes

REGISTRI ED ENTI

Come promemoria, un record è il record fisico del database a cui si accede tramite un’entità. Un’entità è un riferimento a un record (vedere la sezione Entità nel glossario). I record vengono bloccati e sbloccati attraverso le entità.

Bloccaggio ottimistico

Nella chiusura ottimistica, un record viene controllato prima di essere salvato per vedere se altri processi lo hanno modificato da quando è stato caricato in un’entità. Il vantaggio è che il record viene bloccato solo durante il metodo di salvataggio.

Il blocco ottimistico si basa sul timbro dei record. Ogni record ha un timbro interno che viene incrementato automaticamente ogni volta che il record viene salvato nel database. Se un record è stato aggiornato da quando è stata caricata un’entità, i metodi save(), drop() e lock() restituiranno un codice di stato specifico che indica che il timbro è cambiato. Si dovrà quindi decidere cosa fare per gestire questo conflitto.

Per impostazione predefinita, ORDA funziona con il blocco ottimistico, ma è disponibile anche il blocco pessimistico .

ESEMPIO

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"
// Salva il dipendente
$statusSave :=$employee.save()
// Test if the save is successful
If ($statusSave.success)
ALERT ("Salvato con successo!")
End if
End if
// Il record nel database è stato aggiornato

Sono sicuro che siete ansiosi di saperne di più sul locking ottimistico. Un altro post del blog, completamente dedicato a questo concetto, è in arrivo. Restate sintonizzati!

Pessimistic locking

In modalità di locking pessimistico , i record vengono bloccati in lettura, in modo che altri processi non possano aggiornarli. Questo assicura che un record modificato possa essere scritto a scapito dei record bloccati ad altri utenti. Il record è bloccato anche quando non c’è accesso concorrente.

Con il blocco pessimistico, è necessario bloccare i record prima di aggiornarli e sbloccarli dopo l’aggiornamento. Finché un record è bloccato, il salvataggio / l’eliminazione / il blocco del record in altri processi fallirà finché non verrà sbloccato dal processo che lo ha bloccato.

Per bloccare un’entità, utilizzare il metodo lock() e il metodo unlock() per sbloccarla.

Il 4D “classico” utilizza la chiusura pessimistica.

ESEMPIO

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

Non temete di dimenticare di sbloccare un record, ORDA lo sblocca automaticamente se non ci sono più riferimenti all’entità che lo ha bloccato.

Avatar
- Product Owner - Marie-Sophie Landrieu-Yvert è entrata a far parte del team 4D Product come Product Owner nel 2017. In qualità di Product Owner, è incaricata di scrivere le storie degli utenti e di tradurle in specifiche funzionali. Il suo ruolo è anche quello di assicurarsi che l'implementazione della funzionalità fornita soddisfi le esigenze del cliente.Marie-Sophie si è laureata presso la scuola di ingegneria ESIGELEC e ha iniziato la sua carriera come ingegnere presso IBM nel 1995. Ha partecipato a vari progetti (di manutenzione o di costruzione) e ha lavorato come sviluppatrice Cobol. In seguito ha lavorato come progettista UML e sviluppatore Java. Ultimamente i suoi ruoli principali erano l'analisi e la scrittura dei requisiti funzionali, il coordinamento dei team di business e di sviluppo.