In questo articolo illustriamo i meccanismi di lock disponibili sulla piattaforma appian
Non è raro un requisito in cui vi è bisogno di proteggere un record da scritture concorrenti. A tal fine, la piattaforma supporta due meccanismi di lock : il locking ottimistico e pessimistico.
I modelli di lock
I lock dei dati in Appian è implementato secondo due modelli :
- Il lock ottimistico, in cui la scrittura di un record viene verificata (ed eventualmente bloccata) solo al tempo di esecuzione del commit delle modifiche sul database
- Il lock pessimistico, in cui un record viene bloccato appena si richiede di effettuarne la modifica.
In generale entrambi i modelli di lock sono validi soltanto se si è coerenti nella generazione delle scritture al database, vale a dire, in tutti i casi non è garantita la coerenza dei dati a livello di sistema.
Il lock ottimistico
Il lock ottimistico si ottiene aggiungendo un campo integer sulla tabella di cui si vuole implementare i lock.
Prelevo un record con versione 1 e lo modifico, quando lo aggiorno leggo la versione: se il valore della colonna è 1 allora l’aggiornamento è valido, se invece la versione è 2 (o altro) vuol dire che quel record è stato già modificato e quindi devo bloccare l’aggiornamento.
Implementazione
Molto semplicemente, bisogna creare un campo numerico che conterrà la versione del record, successivamente aggiungere l’annotazione @Version sul campo. Dopo aver pubblicato l’entità relativa al CDT, utilizzando lo smartservice write to datastore, in caso di aggiornamenti incoerenti il sistema solleva una StaleObjectStateException che ci avverte che stiamo tentando di sovrascrivere un item già aggiornato.
Considerazioni
- Con StaleObjectStateException il processo che contiene la scrittura è messo in pausa.
- Sarà compito di chi gestisce la piattaforma di risolvere l’incoerenza che si è generata e nel caso scartare il processo scaduto.
- Questo lock funziona correttamente solo se si utilizzano esclusivamente i write to datastore, gli aggiornamenti mediante storedprocedure restano impossibili da controllare.
Il lock Pessimistico
Il lock ottimistico è ben più complesso e meno definito da appian stesso. In sostanza dobbiamo creare un meccanismo che impedisca di recuperare il lock per la modifica in modo da assicurarci che le modifiche siano sempre coerenti.
Implementazione
Abbiamo bisogno di una tabella che contiene i lock. Tale tabella che chiamiamo lockTable dovrà contenere almeno:
- Il nome del tipo dato, in questo esempio chiamiamo tale colonna NameType.
- l’id del record da bloccare, in questo esempio chiamiamo tale colonna idType.
A questo punto definiamo come chiave unique la coppia NameType e idType all’interno della tabella lockTable.
Il passo successivo è creare una stored procedure getLock al cui interno proveremo a scrivere, in transazione, all’interno della tabella lockTable un record con rispettivamente il nome del tipo da modificare in NameType e come idType la chiave primaria. Infine bisogna creare una stored procedure releaseLock in cui si elimina il record dalla tabella lockTable una volta terminata la modifica.
Considerazioni
- In questo caso l’eccezione lanciata dal database sarà chiave duplicata in caso di una getLock di un record già bloccato.
- Sarà compito di chi gestisce la piattaforma di risolvere l’incoerenza che si è generata e nel caso scartare il processo scaduto.
- Questo lock può essere utilizzato sia con stored procedure che con write to entity datastore.
Quale lock scegliere?
Appian consiglia il lock ottimistico : più leggero e facile da implementare, solo in casi estremi bisogna utilizzare il lock pessimistico. La mia risposta invece è dipende, se abbiamo un bisogno assoluto di garantire la coerenza il lock pessimistico è una buona scelta. Nel lock ottimistico un record può essere compromesso mediante stored procedure e in ottica estendibilità non metterei la mano sul fuoco per cui nel corso del tempo non si abbia bisogno di una stored procedure.
Bibliografia
https://community.appian.com/w/the-appian-playbook/196/data-locking-strategies
