Impostazioni di compatibilità – Transazioni annidate (Parte 3)

Benvenuti alla nostra serie di articoli sulle impostazioni di compatibilità e sulle funzioni “nascoste” per migliorare le prestazioni. Nel primo post abbiamo analizzato il comando QUERY BY FORMULA e il suo impatto sul comportamento di un’applicazione. Il secondo post riguardava l’opzione di compatibilità“Usa punto e virgola come segnaposto” per evitare di incorrere nel problema “i numeri vengono visualizzati come >>>>>>>>>” .

In questa terza puntata, esploreremo le transazioni annidate.

Se questa opzione non è visibile nella pagina di compatibilità (perché la struttura è stata creata con 4D v11 o successivo) o è già abilitata, non è necessario continuare a leggere. In caso contrario, l’applicazione è in esecuzione in una modalità che emula 4D v2004. Non solo vi state perdendo un sacco di ottime funzionalità, ma siete anche in una posizione rischiosa, poiché questa modalità non è più testata da 4D.

Quando 4D ha introdotto le transazioni per la prima volta 25 anni fa, supportava solo un singolo livello di transazione: le operazioni erano o meno in una transazione. Tuttavia, da oltre 10 anni 4D supporta le transazioni a più livelli (annidate). Dovreste approfittarne!

Se non avete mai usato le transazioni, vi consiglio di leggere questo post sulle transazioni… altrimenti continuate a leggere!

Flag di compatibilità delle transazioni annidate

Allora, perché c’è un’opzione? Non è meglio usare sempre le transazioni annidate?

Sì, è molto meglio. Tuttavia, il codice esistente potrebbe essere stato scritto solo con transazioni a livello singolo, quindi l’opzione è presente.

START TRANSACTION
START TRANSACTION // second call by accident, ignored from 4D v2004
VALIDATE TRANSACTION // v2004 was now at the end, no transaction running anymore
// v11 still has a transaction open…

Perché? Cosa potrebbe succedere? Sono contento che l’abbiate chiesto! Supponiamo che un utente finale esca da un’applicazione con solo transazioni a livello singolo, che potrebbe avere ancora transazioni aperte non confermate e non validate. Queste verranno automaticamente annullate e tutto il lavoro svolto potrebbe andare perso!

Prima di abilitare il flag di compatibilità delle transazioni nidificate, è necessario rivedere attentamente il codice e assicurarsi che tutte le chiamate alle transazioni siano bilanciate. Verificare che non siano solo aperte, ma anche chiuse. Ad esempio, un metodo chiamato all’interno di una condizione IF potrebbe avviare una transazione, ma potrebbe essere difficile da trovare se il codice non è ben strutturato e organizzato.

Ci sono due modi per verificarlo:

1. Il primo è quello di fare una verifica completa del codice, che potrebbe richiedere molto tempo. Tuttavia, esiste un’altra opzione.
2. Se l’applicazione utilizza un solo processo, potrebbe essere molto semplice. Nell’evento On Exit, verificare se ci sono transazioni ancora aperte. In caso affermativo, segnalarlo (inviare un’e-mail, chiamare l’amministratore, ecc.) E convalidare la transazione (supponendo che si tratti di una transazione aperta per sbaglio).

Poiché molto probabilmente avrete più processi, dovrete identificarli. Se si dispone di un metodo generico che viene chiamato in ogni processo quando lo si avvia o lo si termina, non c’è da preoccuparsi. In caso contrario, dovrete trovare questi processi e modificare ciascuno di essi. Alla fine di ogni processo, controllare il metodo Transaction level.

A questo punto, non fare nient’altro. Prima di iniziare a usare transazioni annidate, controllate il vostro codice!

sospendere le transazioni

Non appena avrete abilitato le transazioni annidate, noterete un altro vantaggio. È possibile premere il pulsante snooze!

Supponiamo di trovarci all’interno di una transazione e di dover aumentare un contatore memorizzato in un’altra tabella(ad esempio, un numero di fattura). Finché la transazione è aperta, tutti i record modificati sono bloccati, in modo che altri utenti o processi non possano modificarli. Se questo può andare bene per la fattura in sé, non è altrettanto positivo per il contatore del numero di fattura. In passato, gli sviluppatori hanno cercato di aggirare il problema avviando un altro processo e creando processi per gestire la comunicazione. Si tratta di un sacco di codice solo per eseguire qualcosa al di fuori di una transazione. Fortunatamente, c’è un modo migliore… non appena le transazioni annidate sono abilitate, è possibile metterle in pausa in qualsiasi momento. In questo modo è possibile incrementare il contatore e riprendere la transazione.

È una funzione talmente fantastica che c’è un intero articolo nella documentazione che la riguarda!

La memoria

Indipendentemente dal fatto che si utilizzino o meno le transazioni annidate, è bene sapere che le transazioni aumentano la memoria richiesta perché i dati modificati vengono memorizzati in un buffer temporaneo. Non solo, ma internamente 4D crea anche indici temporanei che consentono l’esecuzione di query.

Di conseguenza, più grandi sono le tabelle (poiché vengono indicizzati più campi e modificati più record), più memoria è necessaria. Se la memoria è insufficiente, verranno creati dei file temporanei accanto ai file .4DD (per memorizzare il buffer temporaneo). Questi file, pur risolvendo la carenza di memoria, potrebbero ridurre le prestazioni dell’applicazione.

Quindi, anche se le transazioni sono ottime, non è la migliore idea manipolare milioni di record in una singola transazione!