IBM i
Database
Controllo del commit
Versione 7 Release 1
IBM i
Database
Controllo del commit
Versione 7 Release 1
Nota
Prima di utilizzare le presenti informazioni e il prodotto da esse supportato, leggere le
informazioni contenute nella sezione “Informazioni particolari”, a pagina 123.
Questa edizione si applica a IBM i 7.1 (numero prodotto 5770-SS1) e a tutti i release e livelli di modifica successivi,
a meno che non venga diversamente indicato nelle nuove edizioni. La presente versione non viene eseguita su tutti
i modelli RISC (reduced instruction set computer) né sui modelli CISC.
© Copyright IBM Corporation 2003, 2010.
Indice
Controllo del commit . . . . . . . . . 1
Novità in IBM i 7.1 . . . . . . . . . . . . 1
File PDF per il controllo del commit . . . . . . 1
Concetti di controllo del commit . . . . . . . . 2
Modalità di funzionamento del controllo del
commit . . . . . . . . . . . . . . . 2
Modalità di funzionamento delle operazioni di
commit e di rollback . . . . . . . . . . . 3
Operazione di commit . . . . . . . . . 3
Operazione di rollback . . . . . . . . . 4
Definizione di commit . . . . . . . . . . 5
Ambito per una definizione di commit . . . 6
Nomi di definizioni di commit . . . . . . 9
Esempio: lavori e definizioni di commit . . . 10
Modalità di funzionamento del controllo del
commit con gli oggetti. . . . . . . . . . 12
Tipi di risorse di cui è possibile eseguire il
commit . . . . . . . . . . . . . . 12
Risorse di cui è possibile eseguire il commit
locali e remote . . . . . . . . . . . 15
Intento di accesso di una risorsa di cui è
possibile eseguire il commit . . . . . . . 15
Protocollo di commit di una risorsa di cui è
possibile eseguire il commit . . . . . . . 16
File registrati su giornale e controllo del
commit . . . . . . . . . . . . . . 17
Sequenza di voci di giornale sotto il controllo
del commit . . . . . . . . . . . . 17
Identificativo di ciclo di commit . . . . . 20
Blocco di record . . . . . . . . . . . 21
Controllo del commit e lotti dischi indipendenti 22
Considerazioni sui lotti dischi indipendenti
per le definizioni di commit . . . . . . . 22
Considerazioni per le transazioni XA . . . . 25
Considerazioni e limitazioni per il controllo del
commit . . . . . . . . . . . . . . . 25
Controllo del commit per le applicazioni batch
27
Controllo del commit in due fasi . . . . . . 28
Ruoli nell'elaborazione di commit . . . . . 29
Stati della transazione per il controllo del
commit a due fasi . . . . . . . . . . 31
Definizioni di commit per il controllo del
commit in due fasi . . . . . . . . . . 34
Definizione di commit per un commit in
due fasi: consentire VRO (vote read-only) . 35
Definizione di commit per un commit in
due fasi: Non attendere risultato . . . . 37
Definizione di commit per un commit in
due fasi: indicazione di OK tralasciare . . 41
Definizione di commit per un commit in
due fasi: non selezione di un ultimo agent . 43
Effetto della decisione affidabile sul flusso
di elaborazione di commit . . . . . . 44
Supporto delle transazioni XA per il controllo del
commit . . . . . . . . . . . . . . . 46
© Copyright IBM Corp. 2003, 2010
Modalità server SQL e transazioni nell'ambito del
sottoprocesso per il controllo del commit . . . 51
Avvio del controllo del commit . . . . . . . . 52
Oggetto di notifica del commit . . . . . . . 53
Livello di blocco del commit. . . . . . . . 55
Terminazione del controllo del commit . . . . . 58
Terminazione avviata dal sistema del controllo del
commit . . . . . . . . . . . . . . . . 59
Controllo del commit durante la fine del gruppo
di attivazione . . . . . . . . . . . . . 59
Operazioni di commit e di rollback impliciti . . 60
Controllo del commit durante la terminazione
normale del passo di instradamento . . . . . 63
Controllo del commit durante la fine anomala di
lavoro o sistema . . . . . . . . . . . . 64
Aggiornamenti all'oggetto di notifica . . . . . 65
Ripristino del controllo del commit durante l'IPL
(initial program load) dopo la fine anomala . . 67
Gestione di transazioni e controllo del commit. . . 69
Visualizzazione delle informazioni sul controllo
del commit . . . . . . . . . . . . . 69
Visualizzazione di oggetti bloccati per una
transazione . . . . . . . . . . . . 70
Visualizzazione di lavori associati a una
transazione . . . . . . . . . . . . 70
Visualizzazione dello stato risorsa di una
transazione . . . . . . . . . . . . 71
Visualizzazione delle proprietà delle
transazioni . . . . . . . . . . . . 71
Ottimizzazione delle prestazioni per il controllo
del commit . . . . . . . . . . . . . 71
Riduzione al minimo dei blocchi . . . . . 74
Gestione della dimensione della transazione
75
Commit soft . . . . . . . . . . . . 77
Scenari ed esempi: controllo del commit . . . . . 78
Scenario: controllo del commit . . . . . . . 78
Problema pratico per il controllo del commit . . 81
Flusso logico per l'esercizio pratico . . . . 87
Passi associati al flusso logico per il
programma pratico . . . . . . . . . . 89
Esempio: utilizzo di un file di registrazione delle
transazioni per avviare un'applicazione . . . . 90
Esempio: utilizzo di un oggetto di notifica per
avviare un'applicazione . . . . . . . . . 94
Esempio: oggetto di notifica univoco per
ciascun programma. . . . . . . . . . 96
Esempio: oggetto di notifica singolo per tutti
i programmi. . . . . . . . . . . . 100
Esempio: utilizzo di un programma di
elaborazione standard per avviare
un'applicazione. . . . . . . . . . . . 101
Esempio: codice per un programma di
elaborazione standard . . . . . . . . 101
Flusso di elaborazione . . . . . . . 103
Esempio: codice per un programma di
elaborazione di commit standard . . . . . 104
iii
Esempio: utilizzo di un programma di
elaborazione standard per decidere se
riavviare l'applicazione . . . . . . .
Risoluzione dei problemi relativi a transazioni e
controllo del commit . . . . . . . . . .
Errori del controllo del commit . . . . .
Condizioni di errore . . . . . . . .
Condizioni senza errori . . . . . . .
Messaggi di errore da monitorare durante il
controllo del commit . . . . . . . .
Monitoraggio del verificarsi di errori dopo
un comando CALL . . . . . . . .
Errore di elaborazione di commit o rollback
normale . . . . . . . . . . . .
Rilevazione di condizioni di stallo . . . .
iv
IBM i: Database Controllo del commit
. 106
.
.
.
.
107
107
108
109
|
|
Ripristino delle transazioni dopo un errore nelle
comunicazioni . . . . . . . . . . . .
Quando forzare le opzioni di commit e di
rollback e quando annullare la
risincronizzazione . . . . . . . . . . .
Fine di un rollback a lunga esecuzione . . . .
Ricerca di transazioni di grandi dimensioni
oppure obsolete . . . . . . . . . . .
Informazioni correlate per il controllo del commit
116
117
118
119
120
. 110
. 113
. 113
. 115
Appendice. Informazioni particolari
123
Informazioni sull'interfaccia di programmazione
Marchi . . . . . . . . . . . . . .
Termini e condizioni . . . . . . . . . .
125
. 125
. 125
Controllo del commit
Il controllo del commit è una funzione che assicura l'integrità dei dati. Definisce ed elabora un gruppo di
modifiche alle risorse, come ad esempio le tabelle o i file di database, come una transazione.
Il controllo del commit assicura che l'intero gruppo di modifiche individuali venga eseguito su tutti i
sistemi che partecipano alla transazione oppure che non venga eseguita nessuna delle modifiche. DB2 for
IBM® i utilizza la funzione di controllo del commit per eseguire il commit e il rollback delle transazioni di
database in esecuzione con un livello di isolamento diverso da *NONE (nessun commit).
È possibile utilizzare il controllo del commit per progettare un'applicazione in modo che il sistema possa
riavviare l'applicazione se un lavoro, un gruppo di attivazione in un lavoro o il sistema vengono
terminati in modo anomalo. Il controllo del commit consente di garantire che, quando l'applicazione
viene avviata nuovamente, nel database non siano presenti degli aggiornamenti parziali dovuti a
transazioni incomplete dovute a un precedente malfunzionamento.
Nota: utilizzando gli esempi di codice, si accettano i termini indicati nella sezione “Informazioni
sull'esonero di responsabilità e licenza del codice” a pagina 121.
Novità in IBM i 7.1
Questa sezione contiene informazioni nuove o modificate in modo significativo per la raccolta di
argomenti Controllo del commit.
v Supporto per le transazioni di controllo del commit che possono estendersi a un IASP (Independent
ASP) e *SYSBAS senza utilizzare una connessione remota (consultare le sezioni Considerazioni su
Impostazione gruppo ASP e Considerazioni su IPL (initial program load) e disattivazione in
Considerazioni sui lotti dischi indipendenti per le definizioni di commit per informazioni dettagliate).
v Supporto per l'eliminazione di rami transazione XA orfani (consultare la sezione Considerazioni sul
ripristino in Supporto delle transazioni XA per il controllo del commit per informazioni dettagliate).
v Supporto per trovare transazioni di grandi dimensioni oppure obsolete (consultare Ricerca di
transazioni di grandi dimensioni oppure obsolete per informazioni dettagliate).
Come individuare le novità o le modifiche
Per facilitare l'individuazione dei punti in cui sono state apportate modifiche tecniche, queste
informazioni utilizzano:
per segnalare dove iniziano le informazioni nuove o modificate.
v L'immagine
per segnalare dove finiscono le informazioni nuove o modificate.
v L'immagine
Nei file PDF, vengono visualizzate delle barre (|) a sinistra delle informazioni nuove e modificate.
Per individuare ulteriori informazioni relative alle novità o alle modifiche, consultare l'argomento Memo
per gli utenti.
File PDF per il controllo del commit
È possibile visualizzare e stampare un file PDF che contiene le presenti informazioni.
Per visualizzare o scaricare la versione PDF di questo documento, selezionare Controllo del commit (circa
1361 KB).
© Copyright IBM Corp. 2003, 2010
1
Salvataggio di file PDF
Per salvare un PDF sulla stazione di lavoro per la visualizzazione o per la stampa:
1. Fare clic con il tasto destro del mouse sul collegamento PDF nel proprio browser.
2. Selezionare l'opzione che effettua il salvataggio locale del PDF.
3. Andare all'indirizzario in cui si desidera salvare il PDF.
4. Fare clic su Salva.
Scaricamento di Adobe Reader
Per visualizzare o stampare tali PDF, è necessario che sul sistema sia installato Adobe® Reader. È possibile
.
scaricare una copia gratuita dal sito Web Adobe (www.adobe.com/products/acrobat/readstep.html)
Riferimenti correlati
“Informazioni correlate per il controllo del commit” a pagina 120
I manuali dei prodotti, le pubblicazioni IBM Redbooks, i siti Web e altre raccolte di argomenti
dell'information center contengono informazioni correlate alla raccolta di argomenti Controllo del commit.
È possibile visualizzare o stampare qualsiasi file PDF.
Concetti di controllo del commit
Questi concetti di controllo del commit aiutano a comprendere come funziona il controllo del commit,
come interagisce con il sistema e come interagisce con gli altri sistemi nella rete.
Modalità di funzionamento del controllo del commit
Il controllo del commit assicura che l'intero gruppo di modifiche individuali venga applicato su tutti i
sistemi partecipanti oppure che non venga applicata alcuna modifica.
Ad esempio, quando si trasferiscono dei fondi da un conto di risparmio a un conto corrente, viene
applicata più di una modifica come un gruppo. Per l'utente, questo trasferimento sembra essere una
singola modifica. Tuttavia, viene applicata più di una modifica al database perché vengono modificati sia
il conto di risparmio sia il conto corrente. Per fare in modo che entrambi i conti siano accurati, tutte le
modifiche o nessuna delle modifiche devono essere applicate al conto corrente e al conto di risparmio.
Il controllo del commit consente di completare le seguenti attività:
v Assicurarsi che tutte le modifiche in una transazione siano completate per tutte le risorse interessate.
v Assicurarsi che tutte le modifiche in una transazione vengano eliminate se l'elaborazione viene
interrotta.
v Rimuovere le modifiche apportate durante una transazione quando l'applicazione determina che una
transazione è in errore.
È anche possibile progettare un'applicazione in modo che il controllo del commit possa riavviare
l'applicazione se un lavoro, un gruppo di attivazione in un lavoro o il sistema vengono terminati in modo
anomalo. Il controllo del commit consente di garantire che, quando l'applicazione viene avviata
nuovamente, nel database non siano presenti degli aggiornamenti parziali dovuti a transazioni
incomplete dovute a un precedente malfunzionamento.
Transazione
Una transazione è un gruppo di singole modifiche agli oggetti sul sistema che si presenta all'utente come
una singola modifica "atomica" (ossia indivisibile).
2
IBM i: Database Controllo del commit
Nota: System i Navigator utilizza il termine transazione, mentre l'interfaccia basata sui caratteri utilizza il
termine LUW (logical unit of work o unità di lavoro logica). I due termini sono intercambiabili. Questo
argomento, a meno che non faccia specificamente riferimento all'interfaccia basata sui caratteri,
utilizza il termine transazione.
Una transazione può essere una delle seguenti situazioni:
Interrogazioni in cui non si verifica alcuna modifica del file di database.
Semplici transazioni che modificano un singolo file di database.
Transazioni complesse che modificano uno o più file di database.
Transazioni complesse che modificano uno o più file di database, ma queste modifiche rappresentano
solo una parte di un gruppo logico di transazioni.
v Transazioni semplici e complesse che interessano i file di database su più di una singola ubicazione. I
file di database possono essere in una delle seguenti situazioni:
– Su un sistema remoto singolo.
v
v
v
v
– Sul sistema locale e uno o più sistemi remoti.
– Assegnato a più di un giornale sul sistema locale. Ciascun giornale può essere considerato come
un'ubicazione locale.
v Transazioni semplici o complesse sul sistema locale che interessano oggetti diversi dai file di database.
Modalità di funzionamento delle operazioni di commit e di rollback
Le operazioni di commit e di rollback interessano le modifiche apportate sotto il controllo del commit.
I seguenti linguaggi di programmazione e le seguenti API (application programming interface)
supportano le operazioni di commit e di rollback.
Linguaggio o API
Commit
Rollback
CL
Comando COMMIT
Comando ROLLBACK
IBM ILE (Integrated Language
Environment) RPG
Codice operazione COMIT
Codice operazione ROLBK
ILE COBOL
Verbo COMMIT
Verbo ROLLBACK
ILE C
Funzione _Rcommit
Funzione _Rrollbck
PLI
Sottoroutine PLICOMMIT
Sottoroutine PLIROLLBACK
SQL
Istruzione COMMIT
Istruzione ROLLBACK
SQL CLI (Call Level Interface)
Funzione SQLTransact() (Viene utilizzata per eseguire il commit e il rollback
di una transazione)
API XA
API xa_commit() e db2xa_commit()
API xa_rollback() e db2xa_rollback()
Concetti correlati
SQL call level interface
Database programming
Informazioni correlate
PDF del manuale WebSphere Development Studio: ILE C/C++ Programmer's Guide
CL programming
Application programming interfaces
Operazione di commit
Un'operazione di commit rende permanenti tutte le modifiche eseguite sotto il controllo del commit dopo
la precedente operazione di commit o rollback. Il sistema rilascia anche tutti i blocchi correlati alla
transazione.
Controllo del commit
3
Quando riceve una richiesta di esecuzione di un commit, il sistema esegue le seguenti operazioni:
v Il sistema salva l'identificazione di commit, se ne viene fornita una, per l'utilizzo al momento del
ripristino.
v Il sistema scrive i record nel file prima di eseguire l'operazione di commit se ricorrono entrambe le
condizioni qui di seguito indicate:
– I record sono stati aggiunti a un file di database locale o remoto sotto il controllo del commit.
– SEQONLY(*YES) è stato specificato quando il file è stato aperto in modo che il sistema utilizzi il
feedback I/E bloccato ed esista un blocco parziale di record.
Altrimenti, l'area di feedback I/E e i buffer I/E non vengono modificati.
v Il sistema esegue una chiamata al programma di uscita di rollback e di commit per ciascuna risorsa di
commit API presente nella definizione di commit. Se per un'ubicazione è registrato più di un
programma di uscita, il sistema richiama i programmi di uscita per tale ubicazione nell'ordine in cui
erano stati registrati.
v Se sono state eseguite delle modifiche di record per le risorse assegnate a un giornale, il sistema scrive
una voce di giornale C CM in ogni giornale locale associato alla definizione di commit. La sequenza di
voci di giornale sotto il controllo del commit mostra le voci di norma scritte mentre è attiva una
definizione di commit.
v Il sistema rende permanenti le modifiche a livello di oggetto in sospeso.
v Il sistema sblocca i blocchi di record e oggetto acquisiti e mantenuti per scopi di controllo del commit.
Queste risorse sono rese disponibili ad altri utenti.
v Il sistema modifica le informazioni nella definizione di commit per mostrare che la transazione corrente
è stata terminata.
Il sistema deve eseguire tutti i passi precedenti correttamente perché l'operazione di commit abbia esito
positivo.
Concetti correlati
“Definizione di commit” a pagina 5
La definizione di commit contiene informazioni pertinenti alle risorse di cui è in corso la modifica sotto il
controllo del commit durante una transazione.
“Sequenza di voci di giornale sotto il controllo del commit” a pagina 17
Questa tabella mostra la sequenza di voci di norma scritte mentre è attiva una definizione di commit. È
possibile utilizzare il programma di ricerca delle informazioni sulle voci del giornale per ottenere ulteriori
informazioni sul contenuto delle voci di giornale.
Operazione di rollback
Un'operazione di rollback elimina tutte le modifiche apportate dopo la precedente operazione di commit
o rollback. Il sistema rilascia anche tutti i blocchi correlati alla transazione.
Il sistema esegue le seguenti operazioni quando riceve una richiesta di esecuzione di un rollback:
v Il sistema elimina i record dal buffer I/E se ricorrono entrambe queste condizioni:
– Se i record sono stati aggiunti a un file di database locale o remoto sotto il controllo del commit.
– Se SEQONLY(*YES) è stato specificato quando il file è stato aperto in modo che il sistema utilizzi
l'I/E bloccato ed esista un blocco parziale di record che non è stato ancora scritto nel database.
Altrimenti, l'area di feedback I/E e i buffer I/E rimangono invariati.
v Il sistema esegue una chiamata al programma di uscita di rollback o di commit per ciascuna risorsa di
commit API presente nella definizione di commit. Se per un'ubicazione è registrato più di un
programma di uscita, il sistema richiama i programmi di uscita per tale ubicazione in ordine inverso
rispetto a quello in cui erano stati registrati.
v Se un record è stato eliminato da un file, il sistema aggiunge nuovamente il record al file.
v Il sistema rimuove le eventuali modifiche ai record che sono state eseguite durante questa transazione
e rimette i record originali (le immagini-precedenti) nel file.
4
IBM i: Database Controllo del commit
v Se dei record sono stati aggiunti al file durante questa transazione, rimangono nel file come record
cancellati.
v Se sono state eseguite delle modifiche di record per le risorse assegnate a un giornale durante la
transazione, il sistema aggiunge una voce di giornale di C RB al giornale, indicando che si è verificata
un'operazione di rollback. Il giornale contiene anche immagini delle modifiche di record di cui è stato
eseguito il rollback. Prima che venisse richiesta l'operazione di rollback. le immagini-precedenti e le
immagini-successive dei record modificati erano state inserite nel giornale. Il sistema scrive anche la
voce C RB nel giornale predefinito se a tale giornale è assegnata qualche risorsa di cui è possibile
eseguire il commit.
v Il sistema posiziona i file aperti sotto il controllo del commit a una delle seguenti posizioni:
– L'ultimo record cui è stato eseguito l'accesso nella transazione precedente
– Alla posizione di apertura se non è stata eseguita alcuna operazione di commit per il file utilizzando
questa definizione di commit
Questa considerazione è importante se si sta eseguendo un'elaborazione sequenziale.
v Il sistema non esegue il rollback delle modifiche di cui non è possibile eseguire il commit per i file di
database. Ad esempio, i file aperti non vengono chiusi e i file cancellati non vengono ripristinati. Il
sistema non riapre o riposiziona i file chiusi durante questa transazione.
v Il sistema sblocca i blocchi di record acquisiti per scopi di controllo del commit e rende questi record
disponibili ad altri utenti.
v L'identificazione di commit attualmente salvata dal sistema rimane uguale all'identificazione di commit
fornita con l'ultima operazione di commit per la stessa definizione di commit.
v Il sistema inverte le, o esegue il rollback delle, modifiche di cui è possibile eseguire il commit a livello
di oggetto eseguite durante questa transazione.
v I blocchi di oggetto acquisiti per scopi di controllo del commit vengono sbloccati e tali oggetti vengono
resi disponibili ad altri utenti.
v Il sistema stabilisce il limite di commit precedente come limite di commit corrente.
v Il sistema modifica le informazioni nella definizione di commit per mostrare che la transazione corrente
è stata terminata.
Il sistema deve eseguire tutti i passi precedenti correttamente perché l'operazione di rollback abbia esito
positivo.
Definizione di commit
La definizione di commit contiene informazioni pertinenti alle risorse di cui è in corso la modifica sotto il
controllo del commit durante una transazione.
Per creare una definizione di commit, utilizzare il comando STRCMTCTL (Avvio controllo commit) per
avviare il controllo del commit sul sistema. Inoltre, DB2 for i crea automaticamente una definizione di
commit quando il livello di isolamento è diverso da *NONE (nessun commit).
Il sistema conserva le informazioni di controllo del commit nella definizione di commit mentre le risorse
di commit vengono modificate fino al termine della definizione di commit. Ciascuna transazione attiva
sul sistema è rappresentata da una definizione di commit. Una transazione successiva può riutilizzare
una definizione di commit dopo ciascun commit o rollback di una transazione attiva.
Una definizione di commit di norma include le seguenti informazioni:
v I parametri del comando STRCMTCTL.
v Lo stato corrente della definizione di commit.
v Le informazioni sui file di database e altre risorse di cui è possibile eseguire il commit che contengono
modifiche eseguite durante la transazione corrente.
Controllo del commit
5
Per le definizioni di commit con blocchi nell'ambito del lavoro, solo il lavoro che avvia il controllo del
commit conosce tale definizione di commit. Nessun altro lavoro conosce tale definizione di commit.
I programmi possono avviare e utilizzare più definizioni di commit. Ciascuna definizione di commit per
un lavoro identifica una transazione separata cui sono associate delle risorse di cui è possibile eseguire il
commit. È possibile eseguire il commit o il rollback di queste transazioni indipendentemente dalle
transazioni associate ad altre definizioni di commit avviate per il lavoro.
Concetti correlati
“Operazione di commit” a pagina 3
Un'operazione di commit rende permanenti tutte le modifiche eseguite sotto il controllo del commit dopo
la precedente operazione di commit o rollback. Il sistema rilascia anche tutti i blocchi correlati alla
transazione.
“Controllo del commit e lotti dischi indipendenti” a pagina 22
I lotti dischi indipendenti e i gruppi di lotti dischi indipendenti possono ognuno avere un database i5/OS
separato. È possibile utilizzare il controllo del commit con questi database.
“Considerazioni sui lotti dischi indipendenti per le definizioni di commit” a pagina 22
Quando si utilizzano i lotti dischi indipendenti, è necessario tenere presenti le seguenti considerazioni per
le definizioni di commit.
Ambito per una definizione di commit
L'ambito di una definizione di commit determina quali programmi utilizzano questa definizione di
commit e in che modo viene definito l'ambito dei blocchi acquisiti durante le transazioni.
L'interfaccia che avvia la definizione di commit determina l'ambito della definizione di commit. Gli
ambiti possibili per una definizione di commit sono quattro e rientrano in due categorie generali:
Definizioni di commit con blocchi nell'ambito del lavoro
v Definizione di commit a livello di gruppo di attivazione
v Definizione di commit a livello di lavoro
v Definizione di commit denominata esplicitamente
Definizioni di commit con blocchi nell'ambito della transazione
v Definizione di commit nell'ambito della transazione
Le definizioni di commit con blocchi nell'ambito del lavoro possono essere utilizzate solo dai programmi
che vengono eseguiti nel lavoro che ha avviato le definizioni di commit. Al confronto, più di un lavoro
può utilizzare le definizioni di commit con i blocchi nell'ambito della transazione.
Le applicazioni di norma utilizzano le definizioni di commit a livello di gruppo di attivazione o a livello
di lavoro. Queste definizioni di commit vengono create esplicitamente con il comando STRCMTCTL
(Avvio controllo commit) oppure implicitamente dal sistema quando un'applicazione SQL viene eseguita
con un livello di isolamento diverso da *NONE.
Definizione di commit a livello di gruppo di attivazione
L'ambito più comune è quello del gruppo di attivazione. La definizione di commit a livello di gruppo di
attivazione è l'ambito predefinito quando il comando STRCMTCTL avvia esplicitamente la definizione di
commit o quando un'applicazione SQL eseguita con un livello di isolamento diverso da *NONE (nessun
commit) avvia implicitamente la definizione di commit. Solo i programmi eseguiti in tale gruppo di
attivazione utilizzano questa definizione di commit. Per un lavoro, possono essere attive molte definizioni
di commit a livello di gruppo di attivazione alla volta. Tuttavia, ciascuna definizione di commit a livello
di gruppo di attivazione può essere associata solo a un singolo gruppo di attivazione. I programmi
eseguiti in tale gruppo di attivazione possono associare le loro modifiche di cui è possibile eseguire il
commit solo a tale definizione di commit a livello di gruppo di attivazione.
6
IBM i: Database Controllo del commit
Quando System i Navigator, il comando WRKCMTDFN (Gestione definizioni di commit), il comando
DSPJOB (Visualizzazione lavoro) o il comando WRKJOB (Gestione lavoro) visualizzano una definizione di
commit a livello di gruppo di attivazione, questi campi visualizzano le seguenti informazioni:
v Il campo della definizione di commit visualizza il nome del gruppo di attivazione. Mostra il valore
speciale *DFTACTGRP per indicare il gruppo di attivazione predefinito.
v Il campo del gruppo di attivazione visualizza il numero del gruppo di attivazione.
v Il campo del lavoro visualizza il lavoro che ha avviato la definizione di commit.
v Il campo del sottoprocesso visualizza *NONE.
Definizione di commit a livello di lavoro
Una definizione di commit può essere inclusa nell'ambito del lavoro solo immettendo STRCMTCTL
CMTSCOPE (*JOB). Qualsiasi programma in esecuzione in un gruppo di attivazione per cui non è stata
avviata una definizione di commit a livello di gruppo di attivazione utilizza la definizione di commit a
livello di lavoro, se è già stata avviata da un altro programma per il lavoro. È possibile avviare solo una
singola definizione di commit a livello di lavoro per un lavoro.
Quando System i Navigator, il comando WRKCMTDFN (Gestione definizioni di commit), il comando
DSPJOB (Visualizzazione lavoro) o il comando WRKJOB (Gestione lavoro) visualizzano una definizione di
commit a livello di lavoro, questi campi visualizzano le seguenti informazioni:
v Il campo della definizione di commit visualizza il valore speciale *JOB.
v Il campo del gruppo di attivazione viene visualizzato vuoto.
v Il campo del lavoro visualizza il lavoro che ha avviato la definizione di commit.
v Il campo del sottoprocesso visualizza *NONE.
Per uno specifico gruppo di attivazione, i programmi eseguiti in tale gruppo di attivazione possono
utilizzare solo una singola definizione di commit. Pertanto, i programmi eseguiti in un gruppo di
attivazione possono utilizzare la definizione di commit a livello di lavoro o quella a livello di gruppo di
attivazione, ma non entrambe contemporaneamente. In un lavoro a più sottoprocessi che non utilizza la
modalità server SQL, il lavoro transazionale per un programma viene incluso nell'ambito dell'appropriata
definizione di commit rispetto al gruppo di attivazione del programma, indipendentemente da quale
sottoprocesso lo esegue. Se più sottoprocessi utilizzano lo stesso gruppo di attivazione, devono cooperare
per eseguire il lavoro transazionale e assicurare che i commit e i rollback si verifichino al momento
giusto.
Anche quando la definizione di commit a livello di lavoro è attiva per il lavoro, un programma può
comunque avviare la definizione di commit a livello di gruppo di attivazione se nessun programma in
esecuzione in tale gruppo di attivazione ha eseguito operazioni o richieste di controllo del commit per la
definizione di commit a livello di lavoro. Altrimenti, occorre prima terminare la definizione di commit a
livello di lavoro per potere quindi avviare la definizione di commit a livello di gruppo di attivazione. Le
seguenti operazioni o richieste di controllo del commit per la definizione di commit a livello di lavoro
possono impedire l'avvio della definizione di commit a livello di gruppo di attivazione:
v Apertura (piena o condivisa) di un file di database sotto il controllo del commit.
v Utilizzo dell'API QTNADDCR (Aggiunta risorsa di commit) per aggiungere una risorsa di commit API.
v Esecuzione del commit di una transazione.
v Esecuzione del rollback di una transazione.
v Aggiunta di una risorsa remota sotto il controllo del commit.
v Utilizzo dell'API QTNCHGCO (Modifica opzioni di commit) per modificare le opzioni di commit.
v Passaggio della definizione di commit a uno stato di rollback richiesto utilizzando l'API QTNRBRQD
(Rollback richiesto).
Controllo del commit
7
v Invio di una voce di giornale utente che include l'identificativo di ciclo di commit corrente utilizzando
l'API QJOSJRNE (Invio voce di giornale) con il parametro di inclusione dell'identificativo di ciclo di
commit.
In modo analogo, se i programmi in un gruppo di attivazione stanno attualmente utilizzando la
definizione di commit a livello di gruppo di attivazione, è necessario terminare prima la definizione di
commit perché poi i programmi in esecuzione nello stesso gruppo di attivazione possano utilizzare la
definizione di commit a livello di lavoro.
Quando si apre un file di database, l'ambito di apertura per il file aperto può essere al gruppo di
attivazione oppure al lavoro con una limitazione: se il programma sta aprendo un file sotto il controllo
del commit e il file viene incluso nell'ambito del lavoro, il programma che esegue la richiesta di apertura
deve utilizzare la definizione di commit a livello di lavoro.
Definizione di commit denominata esplicitamente
Le definizioni di commit denominate esplicitamente vengono avviate dal sistema quando deve eseguire
delle proprie transazioni di controllo del commit senza interessare le transazioni utilizzate da
un'applicazione. Un esempio di una funzione che avvia questi tipi di definizioni di commit è la
registrazione problemi. Un'applicazione non può avviare delle definizioni di commit denominate
esplicitamente.
Quando System i Navigator, il comando WRKCMTDFN (Gestione definizioni di commit), il comando
DSPJOB (Visualizzazione lavoro) o il comando WRKJOB (Gestione lavoro) visualizzano una definizione di
commit denominata esplicitamente, questi campi visualizzano le seguenti informazioni:
v Il campo di definizione di commit visualizza il nome ad essa assegnato dal sistema.
v Il campo del gruppo di attivazione viene visualizzato vuoto.
v Il campo del lavoro visualizza il lavoro che ha avviato la definizione di commit.
v Il campo del sottoprocesso visualizza *NONE.
Definizioni di commit nell'ambito della transazione
Le definizioni di commit nell'ambito della transazione vengono avviate con le API XA per i blocchi
nell'ambito della transazione.
Queste API utilizzano i protocolli di controllo del commit basati sui sottoprocessi o sulla connessione
SQL, e non quelli basati sul gruppo di attivazione. In altre parole, le API vengono utilizzate per associare
la definizione di commit a uno specifico sottoprocesso o a una specifica connessione SQL mentre viene
eseguito il lavoro transazionale e per eseguire il commit o il rollback delle transazioni. Il sistema collega
queste definizioni di commit ai sottoprocessi che eseguono il lavoro transazionale in base ai protocolli
API. Possono essere utilizzate dai sottoprocessi in lavori differenti.
Quando System i Navigator, il comando WRKCMTDFN (Gestione definizioni di commit), il comando
DSPJOB (Visualizzazione lavoro) o il comando WRKJOB (Gestione lavoro) visualizzano una definizione di
commit a livello della transazione, questi campi visualizzano le seguenti informazioni:
v Il campo della definizione di commit visualizza il valore speciale *TNSOBJ.
v Il campo del gruppo di attivazione viene visualizzato vuoto.
v Il campo del lavoro visualizza il lavoro che ha avviato la definizione di commit. Se invece la
definizione di commit è attualmente collegata a un sottoprocesso, viene visualizzato il lavoro del
sottoprocesso.
v Il campo relativo al sottoprocesso visualizza il sottoprocesso al quale è collegata la definizione di
commit (oppure *NONE, se la definizione di commit non è attualmente collegata ad alcun
sottoprocesso).
8
IBM i: Database Controllo del commit
Riferimenti correlati
XA APIs
Nomi di definizioni di commit
Il sistema attribuisce dei nomi a tutte le definizioni di commit avviate per un lavoro.
La seguente tabella mostra varie definizioni di commit e i loro nomi associati per uno specifico lavoro.
Gruppo di attivazione
Ambito di commit
Nome di definizione di commit
Qualsiasi
Lavoro
*JOB
Gruppo di attivazione predefinito
Gruppo di attivazione
*DFTACTGRP
Gruppo di attivazione denominato
dall'utente
Gruppo di attivazione
Nome del gruppo di attivazione (ad
esempio, PAYROLL)
Gruppo di attivazione denominato
dal sistema
Gruppo di attivazione
Numero del gruppo di attivazione
(ad esempio, 0000000145)
Nessuno
Denominato esplicitamente
QDIR001 (esempio di una definizione
di commit definita dal sistema per
uso esclusivo da parte del sistema). I
nomi di definizioni di commit
definite dal sistema iniziano con Q.
Nessuno
Transazione
*TNSOBJ
Solo i programmi compilati IBM ILE (Integrated Language Environment) possono avviare il controllo del
commit per i gruppi di attivazione diversi dal gruppo di attivazione predefinito. Pertanto, un lavoro può
utilizzare più definizioni di commit solo se sta eseguendo uno o più programmi compilati ILE.
I programmi OPM (Original Program Model) vengono eseguiti nel gruppo di attivazione predefinito e,
per impostazione predefinita, utilizzano la definizione di commit *DFTACTGRP. In un ambiente OPM e
ILE misto, i lavori devono utilizzare la definizione di commit a livello del lavoro se tutte le modifiche di
cui è possibile eseguire il commit apportate da tutti i programmi devono essere sottoposte a commit o a
rollback insieme.
Un file di database aperto incluso nell'ambito di un gruppo di attivazione può essere associato a una
definizione di commit a livello di gruppo di attivazione o a livello di lavoro. Un file di database aperto
incluso nell'ambito del lavoro può essere associato solo alla definizione di commit a livello di lavoro.
Pertanto, qualsiasi programma, OPM o ILE, che apre un file di database sotto il controllo del commit
incluso nell'ambito del lavoro deve utilizzare la definizione di commit a livello di lavoro.
I programmi applicativi non utilizzano il nome di definizione di commit per identificare una specifica
definizione di commit quando si esegue una richiesta di controllo del commit. I nomi di definizione di
commit sono principalmente utilizzati nei messaggi per identificare una specifica definizione di commit
per un lavoro.
Per le definizioni di commit a livello di gruppo di attivazione, il sistema determina quale definizione di
commit utilizzare, sulla base del gruppo di attivazione nel quale è in esecuzione il programma
richiedente. Questo è possibile perché i programmi eseguiti in un gruppo di attivazione in qualsiasi
momento non possono utilizzare che una singola definizione di commit.
Per le transazioni con dei blocchi nell'ambito della transazione, le API XA e gli attributi correlati alle
transazioni aggiunti alla CLI determinano quale definizione di commit è utilizzata dal sottoprocesso
richiamante.
Controllo del commit
9
Informazioni correlate
ILE concepts PDF
Esempio: lavori e definizioni di commit
Questa figura mostra un esempio di un lavoro che utilizza più definizioni di commit.
La figura indica quali aggiornamenti di file sono sottoposti a commit o a rollback a ogni livello di gruppo
di attivazione. L'esempio presume che tutti gli aggiornamenti apportati ai file di database da tutti i
programmi vengano eseguiti sotto il controllo del commit.
10
IBM i: Database Controllo del commit
Controllo del commit
11
La seguente tabella mostra in che modo viene eseguito il commit o il rollback dei file se lo scenario nella
figura precedente subisce delle modifiche.
Esempi aggiuntivi di più definizioni di commit in un lavoro
Modifica nello
scenario
Effetto sulle modifiche a questi file
F1 e F2
F3 e F4
F5 e F6
F7
PGMX esegue
un'operazione di
rollback invece di
un'operazione di
commit (3=
=COMMIT diventa
ROLLBACK).
In sospeso
Sottoposto a rollback
Già sottoposto a
commit
Sottoposto a rollback
PGMZ esegue
un'operazione di
commit prima della
restituzione a PGMX.
In sospeso
Sottoposto a commit
da PGMZ
Già sottoposto a
commit
Sottoposto a commit
In sospeso
Già sottoposto a
commit
In sospeso
Non sotto il controllo
del commit
Già sottoposto a
commit
Il file F7 non può
essere aperto perché
non esiste alcuna
definizione di commit
*JOB (PGMX non l'ha
creata).
In sospeso
PGMZ prova ad
avviare il controllo
del commit
specificando
CMTSCOPE(*ACTGRP)
dopo l'aggiornamento
del file F7. Il tentativo
ha esito negativo
perché le modifiche
sono in sospeso
utilizzando la
definizione di commit
a livello di lavoro.
PGMX non avvia il
controllo del commit
e non apre i file F3 e
F4 con
COMMIT(*YES).
PGMZ prova ad
aprire il file F7 con
COMMIT(*YES).
In sospeso
Modalità di funzionamento del controllo del commit con gli oggetti
Quando viene posto sotto il controllo del commit, un oggetto diventa una risorsa di cui è possibile
eseguire il commit. Viene registrato con la definizione di commit. Partecipa a ogni operazione di commit
e di rollback eseguita per la definizione di commit.
I
v
v
v
v
seguenti argomenti descrivono questi attributi di una risorsa di cui è possibile eseguire il commit:
Tipo di risorsa
Ubicazione
Protocollo di commit
Intento di accesso
Tipi di risorse di cui è possibile eseguire il commit
Questa tabella elenca i tipi differenti di risorse di cui è possibile eseguire il commit, inclusi FILE, DDL
(Data Definition Language), DDM (distributed data management), LU (logical unit) 6.2, DRDA
(Distributed Relational Database Architecture, API e TCP.
12
IBM i: Database Controllo del commit
La tabella visualizza i seguenti elementi:
v I tipi di risorse di cui è possibile eseguire il commit.
v Come vengono posti sotto il controllo del commit.
v Come vengono rimossi dal controllo del commit.
v Le limitazioni che si applicano al tipo di risorsa.
Tipo di risorsa
Come metterla sotto
il controllo del
commit
Quali tipi di
Come rimuoverla dal modifiche è possibile
controllo del commit sottoporre a commit Limitazioni
FILE- file di database
locali
Aprendola sotto il
controllo del commit1
Chiudendo il file, se
non c'è alcuna
modifica in sospeso.
Modifiche a livello di
record
Per una singola
transazione non
possono essere
bloccate più di 500
000 000 record2.
Modifiche a livello di
oggetto, come:
Solo delle modifiche a
livello di oggetto
eseguite utilizzando
SQL sono sotto il
controllo del commit.
Se delle modifiche
sono in sospeso
quando il file viene
chiuso, dopo
l'esecuzione della
successiva operazione
di commit o di
rollback.
DDL- modifiche a
livello di oggetto per
le raccolte SQL e le
tabelle SQL locali.
Eseguendo SQL sotto
il controllo del
commit
Eseguendo
un'operazione di
commit o di rollback
dopo la modifica a
livello di oggetto.
v Creazione di un
pacchetto SQL
v Creazione di una
tabella SQL
v Eliminazione di
una tabella SQL
DDM- file DDM
(distributed data
management) remoto
Aprendo sotto il
controllo del commit.
Il supporto del
controllo del commit
per DDM contiene
ulteriori informazioni
sul controllo del
commit e sulla
gestione dei dati
distribuiti.
Chiudendo il file, se
non c'è alcuna
modifica in sospeso.
Modifiche a livello di
record
Se delle modifiche
sono in sospeso
quando il file viene
chiuso, dopo
l'esecuzione della
successiva operazione
di commit o di
rollback.
LU 6.2- conversazione Avviando la
protetta
conversazione3
Terminando la
conversazione
DRDA- database
Utilizzando
relazionale distribuito l'istruzione SQL
CONNECT
Terminando la
connessione
Controllo del commit
13
Come metterla sotto
il controllo del
commit
Quali tipi di
Come rimuoverla dal modifiche è possibile
controllo del commit sottoporre a commit Limitazioni
API- risorsa di
commit API locale
API QTNADDCR
(Aggiunta di risorsa
di commit)
API QTNRMVCR
(Rimozione risorse di
commit)
Connessione
TCP-TCP/IP
Utilizzando
l'istruzione SQL
CONNECT a un RDB
definito per utilizzare
connessioni TCP/IP o
aprendo un file DDM
definito con
un'ubicazione TCP/IP
Terminando la
connessione SQL o
chiudendo il file
DDM se non ci sono
modifiche in sospeso.
Se il file DDM viene
chiuso con delle
modifiche in sospeso,
la connessione viene
chiusa dopo
l'esecuzione della
successiva operazione
di commit o di
rollback.
Tipo di risorsa
Questo viene
determinato dal
programma utente.
Le voci di giornale
possono essere scritte
dal programma
utente utilizzando
l'API QJOSJRNE
(Invio voce di
giornale) per un
ausilio nel tracciare
queste modifiche.
L'applicazione deve
fornire un
programma di uscita
da richiamare durante
le operazioni di
commit, rollback o
risincronizzazione.
Note:
1
Per informazioni dettagliate su come mettere un file di database sotto il controllo del commit, consultare il
manuale di riferimento al linguaggio appropriato. Le informazioni correlate per il controllo del commit collegano
ai manuali relativi al linguaggio che è possibile utilizzare.
2
È possibile utilizzare un file QAQQINI per ridurre il limite di 500 000 000. Consultare “Gestione della
dimensione della transazione” a pagina 75 per istruzioni.
3
Quando viene avviata una connessione DDM, il file DDM specifica PTCCNV(*YES) e il file DDM è definito con
un'ubicazione remota SNA; una risorsa LU 6.2 viene aggiunta con la risorsa DDM.
Quando viene avviata una connessione DRDA, una risorsa LU 6.2 viene aggiunta con la risorsa DRDA se ricorrono
entrambe le seguenti condizioni:
v Il programma sta utilizzando i protocolli di connessione di unità di lavoro distribuita.
v La connessione è a un RDB (rational database) definito con un'ubicazione remota SNA. Per ulteriori informazioni
sull'avvio di conversazioni protette, consultare il manuale APPC Programming
14
IBM i: Database Controllo del commit
.
Concetti correlati
Distributed database programming
“Aggiornamenti all'oggetto di notifica” a pagina 65
Il sistema aggiorna l'oggetto di notifica con l'identificazione di commit dell'ultima operazione di commit
eseguita correttamente per tale definizione di commit.
Riferimenti correlati
Add Commitment Resource (QTNADDCR) API
Remove Commitment Resource (QTNRMVCR) API
Send Journal Entry (QJOSJRNE) API
Risorse di cui è possibile eseguire il commit locali e remote
Una risorsa di cui è possibile eseguire il commit può essere una risorsa locale o una risorsa remota.
Risorsa locale di cui è possibile eseguire il commit
Una risorsa locale di cui è possibile eseguire il commit si trova sullo stesso sistema dell'applicazione.
Ciascun giornale associato alle risorse sotto il controllo del commit può essere considerato come
un'ubicazione locale. Tutte le risorse registrate senza un giornale (facoltativamente sia per le risorse DDL
sia per le risorse API) possono essere considerate come un'ubicazione locale separata.
Se una risorsa di cui è possibile eseguire il commit si trova in un lotto dischi indipendente e la
definizione di commit si trova in un lotto dischi differente, la risorsa non viene considerata locale.
Risorse remote di cui è possibile eseguire il commit
Una risorsa remota di cui è possibile eseguire il commit si trova su un sistema differente rispetto
all'applicazione. Esiste un'ubicazione remota per ciascuna conversazione univoca con un sistema remoto.
Una definizione di commit potrebbe avere una o più ubicazioni remote su uno o più sistemi remoti.
Quando si pone una risorsa locale sotto il controllo del commit per il lotto dischi di sistema, o qualsiasi
lotto dischi indipendente, è necessario utilizzare DRDA (Distributed Relational Database Architecture) per
accedere alle risorse sotto il controllo del commit in qualsiasi altro lotto dischi indipendente.
La seguente tabella mostra i tipi di risorse di cui è possibile eseguire il commit e le loro ubicazioni.
Tipo di risorsa
Ubicazione
API
Locale
DDL
Locale
DDM
Remota
DRDA
Locale o remota
FILE
Locale
LU62
Remota
TCP
Remota
Concetti correlati
“Controllo del commit e lotti dischi indipendenti” a pagina 22
I lotti dischi indipendenti e i gruppi di lotti dischi indipendenti possono ognuno avere un database i5/OS
separato. È possibile utilizzare il controllo del commit con questi database.
Intento di accesso di una risorsa di cui è possibile eseguire il commit
L'intento di accesso determina in che modo le risorse compartecipano a una transazione.
Controllo del commit
15
Quando una risorsa viene posta sotto il controllo del commit, il gestore risorsa indica come si accede alla
risorsa:
v Aggiorna
v Sola lettura
v Indeterminato
La seguente tabella mostra quali intenti di accesso sono possibili per uno specifico tipo di risorsa e in che
modo il sistema determina l'intento di accesso per una risorsa quando ne viene eseguita la registrazione.
Come viene determinato l'intento di
accesso
Tipo di risorsa
Possibili intenti di accesso
FILE
Aggiorna, sola lettura
In base al modo in cui è stato aperto
il file
DDL
Aggiorna
Aggiorna sempre
API
Aggiorna
Aggiorna sempre
DDM
Aggiorna, sola lettura
In base al modo in cui è stato aperto
il file
LU62
Indeterminato
Sempre indeterminato
DRDA
Aggiorna, sola lettura, indeterminato
Per DRDA Livello 1, l'intento di
accesso è aggiorna se non sono
registrate altre risorse remote.
Altrimenti l'intento di accesso è sola
lettura. Per DRDA Livello 2, l'intento
di accesso è sempre indeterminato.
TCP
Indeterminato
Sempre indeterminato
L'intento di accesso delle risorse che sono già registrate determina se è possibile registrare una nuova
risorsa. Si applicano le seguenti regole:
v Una risorsa in una fase il cui intento di accesso è aggiorna non può essere registrata quando ricorre
una qualsiasi delle seguenti condizioni:
– Le risorse il cui intento di accesso è aggiorna sono già registrate su altre ubicazioni.
– Le risorse il cui intento di accesso è indeterminato sono già registrate su altre ubicazioni.
– Le risorse il cui intento di accesso è indeterminato sono già registrate sulla stessa ubicazione e le
risorse sono state modificate durante la transazione corrente.
v Una risorsa in due fasi il cui intento di accesso è aggiorna non può essere registrata quando una risorsa
in una fase il cui intento di accesso è aggiorna è già registrata.
Protocollo di commit di una risorsa di cui è possibile eseguire il commit
Il protocollo di commit è la capacità che ha una risorsa di partecipare a un'elaborazione di commit in una
fase o in due fasi. Le risorse locali, fatta eccezione per le risorse di cui è possibile eseguire il commit API,
sono sempre delle risorse in due fasi.
Se una risorsa di cui è possibile eseguire il commit si trova in un lotto dischi indipendente e la
definizione di commit si trova in un lotto dischi differente, la risorsa non viene considerata come una
risorsa locale o una risorsa in due fasi.
Una risorsa in due fasi è detta anche risorsa protetta. Le risorse remote e le risorse di cui è possibile
eseguire il commit API devono essere registrate come risorse in una fase o come risorse in due fasi
quando vengono poste sotto il controllo del commit. La seguente tabella mostra quali tipi di risorse di cui
è possibile eseguire il commit possono coesistere in una definizione di commit con una risorsa in una
fase.
16
IBM i: Database Controllo del commit
Tipo di risorsa
Può coesistere con
Risorsa API in una fase
Altre risorse locali. Nessuna risorsa remota.
Risorsa remota in una fase
Altre risorse in una fase nella stessa ubicazione. Nessuna
risorsa locale.
Concetti correlati
“Controllo del commit e lotti dischi indipendenti” a pagina 22
I lotti dischi indipendenti e i gruppi di lotti dischi indipendenti possono ognuno avere un database i5/OS
separato. È possibile utilizzare il controllo del commit con questi database.
File registrati su giornale e controllo del commit
È necessario registrare su giornale (registrazione) un file di database (tipo di risorsa FILE o DDM) prima
che possa essere aperto per l'emissione sotto il controllo del commit o prima che un'applicazione SQL,
che utilizza un livello di isolamento diverso da *NONE (nessun commit), possa fare riferimento a essa.
Un file non deve necessariamente essere registrato su giornale per aprirlo per operazioni limitate
all'immissione sotto il controllo del commit.
Viene notificato un errore se si verifica una delle seguenti condizioni:
v È stato effettuato un tentativo di aprire un file di database per l'emissione sotto il controllo del commit
ma il file non è attualmente registrato su giornale.
v Non è avviata alcuna definizione di commit che può essere utilizzata dal file aperto sotto il controllo
del commit.
Se si stanno registrando su giornale solo le immagini-successive per un file di database aperto sotto il
controllo del commit, il sistema avvia automaticamente la registrazione su giornale sia per le
immagini-precedenti sia per le immagini-successive. Le immagini-precedenti vengono scritte solo per le
modifiche al file che si verificano sotto il controllo del commit. Se contemporaneamente vengono
apportate al file delle altre modifiche che non sono sotto il controllo del commit, per esse vengono scritte
solo le immagini-successive.
Il sistema scrive automaticamente le modifiche di cui è possibile eseguire il commit a livello di record e le
modifiche di cui è possibile eseguire il commit a livello di oggetto in un giornale. Per le modifiche a
livello di record, il sistema utilizza quindi le voci di giornale, se necessario, per scopi di ripristino; il
sistema non utilizza le voci per le modifiche di cui è possibile eseguire il commit a livello di oggetto per
scopi di ripristino. Inoltre, il sistema non scrive automaticamente le voci di giornale per le risorse di
commit API. Tuttavia, il programma di uscita per la risorsa API può utilizzare l'API QJOSJRNE (Invio
voce di giornale) per scrivere le voci di giornale per fornire una traccia di controllo o per essere di ausilio
nel ripristino. Il contenuto di queste voci è controllato dal programma di uscita utente.
Per eseguire il ripristino per le risorse di commit a livello di oggetto, il sistema utilizza un'altra tecnica,
non il giornale. Il ripristino per le risorse di commit API viene eseguito richiamando il programma di
uscita di commit e rollback associato a ogni specifica risorsa di commit API. È responsabilità del
programma di uscita eseguire l'effettivo ripristino necessario per la situazione.
Concetti correlati
Journal management
Sequenza di voci di giornale sotto il controllo del commit
Questa tabella mostra la sequenza di voci di norma scritte mentre è attiva una definizione di commit. È
possibile utilizzare il programma di ricerca delle informazioni sulle voci del giornale per ottenere ulteriori
informazioni sul contenuto delle voci di giornale.
Le voci di controllo del commit vengono scritte in un giornale locale se ricorre almeno una delle seguenti
condizioni:
v Il giornale è specificato come giornale predefinito nel comando STRCMTCTL (Avvio controllo commit).
Controllo del commit
17
v Almeno un file registrato su giornale è aperto sotto il controllo del commit.
v Almeno una risorsa di commit API associata al giornale è registrata sotto il controllo del commit.
Tipo di voce
Descrizione
Dove è scritta
Quando è scritta
C BC
Avvio del controllo del
commit
Nel giornale predefinito, se
ne è specificata una nel
comando STRCMTCTL.
Quando viene utilizzato il
comando STRCMTCTL.
Nel giornale.
Quando il primo file
registrato su un giornale
viene aperto o quando una
risorsa API viene registrata
per un giornale.
Nel giornale.
Quando si verifica la prima
modifica di record per la
transazione per un file
registrato su questo
giornale1.
Nel giornale per una
risorsa API.
Quando l'API QJOSJRNE
viene utilizzata per la
prima volta con la chiave di
inclusione dell'identificativo di
ciclo di commit.
C SC
Avvio del ciclo di commit
Codici giornale D ed F
Voci a livello di oggetto
DDL
Quando si verificano degli
Nel giornale associato
aggiornamenti.
all'oggetto di cui si sta
eseguendo l'aggiornamento.
Solo le voci di giornale che
contengono un
identificativo di ciclo di
commit rappresentano una
modifica a livello di
oggetto DDL che fa parte
della transazione.
Codice giornale R
Voci a livello di record
Nel giornale associato al
file di cui si sta eseguendo
l'aggiornamento.
Quando si verificano gli
aggiornamenti.
Codice giornale U
Voci create dall'utente
Nel giornale associato a
una risorsa API.
Quando l'API QJOSJRNE
viene utilizzata per la
prima volta con la chiave di
inclusione dell'identificativo di
ciclo di commit.
C CM
Commit
Nel giornale.
Dopo che il commit è stato
completato correttamente.
Nel giornale predefinito.
Se delle risorse di cui è
possibile eseguire il commit
sono associate al giornale.
Nel giornale.
Dopo che l'operazione di
rollback è stata completata.
Nel giornale predefinito.
Se delle risorse di cui è
possibile eseguire il commit
sono associate al giornale.
C RB
18
Rollback
IBM i: Database Controllo del commit
Tipo di voce
Descrizione
Dove è scritta
Quando è scritta
C LW
Termine della transazione
Nel giornale predefinito, se Dopo che l'operazione di
commit o di rollback è stata
ne è specificata una nel
completata.
comando STRCMTCTL. Il
sistema scrive un record di
intestazione LW e uno o
più record di dettaglio.
Queste voci vengono scritte
solo se OMTJRNE(*NONE)
viene specificato nel
comando STRCMTCTL o se
si verifica un errore di
sistema.
C EC
Termine del controllo del
commit
Nel giornale.
Dopo che il comando
ENDCMTCTL (Fine
controllo commit) è stato
completato.
In un giornale locale che
non è il giornale
predefinito.
Quando viene stabilito un
limite di commit, dopo il
punto in cui tutte le risorse
di cui è possibile eseguire il
commit associate a tale
giornale sono state rimosse
dal controllo del commit.
C SB
Avvio di punto di
salvataggio o ciclo di
commit nidificato.
Nel giornale.
Quando l'applicazione crea
un SQL SAVEPOINT o
quando il sistema crea un
ciclo di commit nidificato
interno per gestire una serie
di funzioni database come
una singola operazione2.
C SQ
Rilascio del punto di
salvataggio o esecuzione
del commit del ciclo di
commit nidificato.
Nel giornale.
Quando l'applicazione
rilascia un SQL
SAVEPOINT o quando il
sistema esegue il commit di
un ciclo di commit
nidificato internamente2.
C SU
Rollback del punto di
salvataggio o del ciclo di
commit nidificato.
Nel giornale.
Quando l'applicazione
esegue il rollback di un
SQL SAVEPOINT o quando
il sistema esegue il rollback
di un ciclo di commit
nidificato internamente2.
Controllo del commit
19
Tipo di voce
Descrizione
Dove è scritta
Quando è scritta
Note:
1
È possibile specificare che la parte a lunghezza fissa della voce di giornale includa le informazioni sulla
transazione specificando il valore *LUW (relativo all'unità di lavoro logica) per il parametro FIXLENDTA (relativo ai
dati a lunghezza fissa) del comando CRTJRN (Creazione giornale) o CHGJRN (Modifica giornale). Specificando il
parametro FIXLENDTA (*LUW), la parte a lunghezza fissa di ciascuna voce di giornale C SC conterrà il LUWID
(Logical Unit of Work ID, ossia l'ID unità di lavoro logica) della transazione corrente. Allo stesso modo, per le
transazioni XA, se si specifica il parametro FIXLENDTA (*XID), la parte a lunghezza fissa di ciascuna voce di
giornale C SC conterrà l'XID della transazione corrente. Il LUWID o l'XID possono essere di ausilio nel trovare tutti
i cicli di commit per una specifica transazione se la transazione coinvolge più giornali o sistemi.
2
Queste voci vengono inviate solo se si imposta la variabile di ambiente QTN_JRNSAVPT_MYLIB_MYJRN su *YES,
dove MYJRN è il giornale che si sta utilizzando e MYLIB è la libreria in cui è memorizzato il giornale. Il valore
speciale *ALL è supportato per i valori MYLIB e MYJRN. È possibile impostare queste variabili a livello dell'intero
sistema oppure per uno specifico lavoro. Per fare in modo che le voci vengano inviate per il giornale
MYLIB/MYJRN per un solo lavoro, utilizzare questo comando in tale lavoro:
v ADDENVVAR ENVVAR(QTN_JRNSAVPT_MYLIB_MYJRN) VALUE(*YES)
Per fare in modo che le voci vengano inviate per tutti i giornali per tutti i lavori, utilizzare questo comando:
v ADDENVVAR ENVVAR('QTN_JRNSAVPT_*ALL_*ALL') VALUE(*YES) LEVEL(*SYS)
|
|
|
|
|
Il valore di questa variabile di ambiente viene memorizzato in cache internamente per ogni definizione di commit la
prima volta che una risorsa correlata a uno specifico giornale viene posta sotto il controllo del commit. Se la
variabile di ambiente viene modificata dopo tale punto, il valore memorizzato nella cache deve essere aggiornato
perché diventi effettivo per tale giornale. Qualsiasi chiamata dell'API di richiamo di informazioni di commit
QTNRCMTI aggiorna il valore memorizzato nella cache nel lavoro chiamante.
Concetti correlati
“Operazione di commit” a pagina 3
Un'operazione di commit rende permanenti tutte le modifiche eseguite sotto il controllo del commit dopo
la precedente operazione di commit o rollback. Il sistema rilascia anche tutti i blocchi correlati alla
transazione.
Journal entry information finder
Riferimenti correlati
End Commitment Control (ENDCMTCTL) command
Identificativo di ciclo di commit
Un ciclo di commit è il tempo che intercorre tra un limite di commit e il successivo. Il sistema assegna un
identificativo di ciclo di commit per associare tra di loro tutte le voci di giornale per uno specifico ciclo di
commit. Ciascun giornale che partecipa a una transazione ha un proprio ciclo di commit e un proprio
identificativo di ciclo di commit.
L'identificativo di ciclo di commit è il numero di sequenza del giornale della voce di giornale C SC scritta
per il ciclo di commit. L'identificativo di ciclo di commit viene inserito in ciascuna voce di giornale scritta
durante il ciclo di commit. Se viene utilizzato più di un giornale durante il ciclo di commit,
l'identificativo di ciclo di commit per ciascun giornale è differente.
È possibile specificare che la parte a lunghezza fissa della voce di giornale includa le informazioni sulla
transazione specificando il valore *LUW (relativo all'unità di lavoro logica) per il parametro FIXLENDTA
(relativo ai dati a lunghezza fissa) del comando CRTJRN (Creazione giornale) o CHGJRN (Modifica
giornale). Specificando il parametro FIXLENDTA (*LUW), la parte a lunghezza fissa di ciascuna voce di
giornale C SC conterrà il LUWID (Logical Unit of Work ID, ossia l'ID unità di lavoro logica) della
transazione corrente. Allo stesso modo, per le transazioni XA, se si specifica il parametro FIXLENDTA
(*XID), la parte a lunghezza fissa di ciascuna voce di giornale C SC conterrà l'XID della transazione
20
IBM i: Database Controllo del commit
corrente. Il LUWID o l'XID possono essere di ausilio nel trovare tutti i cicli di commit per una specifica
transazione se la transazione coinvolge più giornali o sistemi.
È possibile utilizzare l'API QJOSJRNE (Invio voce di giornale) per scrivere le voci di giornale per le
risorse API. Si dispone dell'opzione di includere l'identificativo di ciclo di commit in queste voci di
giornale.
È possibile utilizzare l'identificativo di ciclo di commit per applicare/eliminare modifiche registrate su
giornale a/da un limite di commit utilizzando il comando APYJRNCHG (Applicazione modifiche
giornale) oppure il comando RMVJRNCHG (Eliminazione modifiche giornale). Si applicano le seguenti
limitazioni:
v La maggior parte delle modifiche a livello di oggetto eseguite sotto il controllo del commit sono scritte
nel giornale ma non sono applicate o eliminate utilizzando i comandi APYJRNCHG e RMVJRNCHG.
v L'API QJOSJRNE scrive le voci di giornale create dall'utente con un codice giornale di U. Queste voci
non possono essere applicate o eliminate utilizzando i comandi APYJRNCHG e RMVJRNCHG. Devono
essere applicate o eliminate con un programma scritto dall'utente.
Blocco di record
Quando un lavoro detiene un blocco del record e un altro lavoro prova a richiamare tale record per
l'aggiornamento, il lavoro richiedente attende e viene rimosso dall'elaborazione attiva.
Il lavoro richiedente sarà inattivo finché non si verifica uno dei seguenti eventi:
v Il blocco del record viene rilasciato.
v Il tempo di attesa specificato termina.
Più di un lavoro può richiedere un record bloccato da un altro lavoro. Quando il blocco del record viene
rilasciato, il record viene ricevuto dal primo lavoro che lo richiede. Quando si attende un record bloccato,
specificare il tempo di attesa nel parametro WAITRCD nei seguenti comandi di creazione, modifica o
sostituzione:
v CRTPF (Creazione file fisico)
v CRTLF (Creazione file logico)
v CRTSRCPF (Creazione file fisico origine)
v CHGPF (Modifica file fisico)
v CHGLF (Modifica file logico)
v CHGSRCPF (Modifica file fisico origine)
v OVRDBF (Sostituzione file di database)
Quando si specifica il tempo di attesa, considerare le seguenti informazioni:
v Se non si specifica un valore, il programma attende per il tempo di attesa predefinito per il processo.
v Per le definizioni di commit che hanno solo blocchi nell'ambito della transazione, il tempo di attesa
predefinito del lavoro può essere sovrascritto da un tempo di attesa di blocco della transazione che può
essere specificato:
– Nell'API xa_open.
– In un'interfaccia JDBC o JTA. Le transazioni distribuite elencano queste API.
v Se il record non può essere assegnato entro il tempo specificato, viene inviato un messaggio di notifica
al programma HLL (high-level language).
v Se il tempo di attesa per un record viene superato, il messaggio inviato alla registrazione lavoro
fornisce il nome del lavoro che detiene il record bloccato che ha causato l'attesa per il lavoro
richiedente. Se si verificano delle eccezioni di blocco del record, è possibile utilizzare la registrazione
lavoro come ausilio nel determinare quali programmi modificare in modo che non detengano dei
blocchi per lunghi periodi.
Controllo del commit
21
I programmi detengono dei blocchi di record per lunghi periodi per uno dei seguenti motivi:
v Il record rimane bloccato mentre l'utente della stazione di lavoro sta considerando una modifica.
v Il blocco del record fa parte di una lunga transazione di commit. Considerare l'esecuzione di
transazioni più piccole per consentire un'esecuzione più frequente di un'operazione di commit.
v Si è verificato un blocco indesiderato. Si presuma, ad esempio, che un file è definito come un file di
aggiornamento con delle chiavi univoche e che il programma aggiorni e aggiunga ulteriori record al
file. Se l'utente della stazione di lavoro desidera aggiungere un record al file, il programma potrebbe
provare ad accedere al record per determinare se la chiave esiste già. In questo caso, il programma
informa l'utente della stazione di lavoro che la richiesta eseguita non è valida. Quando il record viene
richiamato dal file, esso viene bloccato finché non viene rilasciato in modo implicito da un'altra
operazione di lettura sullo stesso file o finché non viene rilasciato esplicitamente.
Nota: per ulteriori informazioni su come utilizzare l'interfaccia HLL (high-level language) per rilasciare
i blocchi del record, consultare l'appropriato manuale di riferimento HLL (high-level language).
Le informazioni correlate per il controllo del commit hanno dei collegamenti ai manuali HLL
(high-level language) che è possibile utilizzare con il controllo del commit.
La durata del blocco è molto più lunga se viene specificato LCKLVL(*ALL) perché il record che era
stato richiamato dal file viene bloccato finché non si verifica la successiva operazione di commit o di
rollback. Non viene rilasciato in modo implicito da un'altra operazione di lettura e non può essere
rilasciato in modo esplicito.
Un'altra funzione che può mettere un blocco su un file è la funzione di salvataggio durante l'utilizzo.
Concetti correlati
Transazioni distribuite JDBC
Funzione salva-mentre-attivo
Riferimenti correlati
“Informazioni correlate per il controllo del commit” a pagina 120
I manuali dei prodotti, le pubblicazioni IBM Redbooks, i siti Web e altre raccolte di argomenti
dell'information center contengono informazioni correlate alla raccolta di argomenti Controllo del commit.
È possibile visualizzare o stampare qualsiasi file PDF.
Controllo del commit e lotti dischi indipendenti
I lotti dischi indipendenti e i gruppi di lotti dischi indipendenti possono ognuno avere un database i5/OS
separato. È possibile utilizzare il controllo del commit con questi database.
Tuttavia, poiché ogni lotto dischi indipendente o gruppo di lotti dischi indipendente ha un database SQL
separato, occorre tener presente alcune considerazioni.
Concetti correlati
“Definizione di commit” a pagina 5
La definizione di commit contiene informazioni pertinenti alle risorse di cui è in corso la modifica sotto il
controllo del commit durante una transazione.
“Risorse di cui è possibile eseguire il commit locali e remote” a pagina 15
Una risorsa di cui è possibile eseguire il commit può essere una risorsa locale o una risorsa remota.
“Protocollo di commit di una risorsa di cui è possibile eseguire il commit” a pagina 16
Il protocollo di commit è la capacità che ha una risorsa di partecipare a un'elaborazione di commit in una
fase o in due fasi. Le risorse locali, fatta eccezione per le risorse di cui è possibile eseguire il commit API,
sono sempre delle risorse in due fasi.
Considerazioni sui lotti dischi indipendenti per le definizioni di commit
Quando si utilizzano i lotti dischi indipendenti, è necessario tenere presenti le seguenti considerazioni per
le definizioni di commit.
22
IBM i: Database Controllo del commit
Considerazioni sulla libreria QRECOVERY
Quando si avvia il controllo del commit, la definizione di commit viene creata nella libreria
QRECOVERY. Ogni lotto dischi indipendente o gruppo di lotti dischi indipendenti ha la propria versione
di una libreria QRECOVERY. Su un lotto dischi indipendente, il nome della libreria QRECOVERY è
QRCYxxxxx, dove xxxxx è il numero del lotto dischi indipendente. Ad esempio, il nome della libreria
QRECOVERY per il lotto dischi indipendente 39 è QRCY00039. Inoltre, se il lotto dischi indipendente fa
parte di un gruppo di lotti dischi, solo il lotto dischi primario ha una libreria QRCYxxxxx.
Quando si avvia il controllo del commit, la definizione di commit viene creata nella libreria QRECOVERY
del lotto dischi indipendente associato a tale lavoro, rendendo il controllo del commit attivo sul lotto
dischi indipendente.
Considerazioni su Impostazione gruppo ASP
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Utilizzare il comando SETASPGRP (Impostazione gruppo ASP) mentre il controllo del commit è attivo su
un lotto dischi indipendente ha i seguenti effetti:
v Se si passa da un lotto dischi indipendente a un altro e le risorse sono registrate con il controllo del
commit sul lotto dischi, il comando SETASPGRP ha esito negativo con il messaggio CPDB8EC, codice
errore 2, Nel sottoprocesso è presente una transazione non sottoposta a commit. Questo
messaggio è seguito dal messaggio CPFB8E9.
v Se si passa da un lotto dischi indipendente a un altro e nessuna risorsa è registrata con il controllo del
commit, le definizioni di commit vengono spostate al lotto dischi indipendente cui si sta passando.
v Se si passa dal lotto dischi di sistema (gruppo ASP *NONE) a un altro, il controllo del commit rimane
invariato. Le definizioni di commit restano sul lotto dischi di sistema. Se, successivamente, si
posizionano le risorse del lotto dischi indipendente sotto il controllo del commit prima delle risorse del
lotto dischi di sistema, la definizione di commit viene spostata al lotto dischi indipendente.
v Se si utilizza un oggetto di notifica, l'oggetto di notifica deve trovarsi sullo stesso lotto dischi
indipendente o gruppo di lotti dischi indipendenti della definizione di commit.
v Se si sposta la definizione di commit in un altro lotto dischi indipendente o gruppo di lotti dischi
indipendenti, anche l'oggetto di notifica deve trovarsi sull'altro lotto dischi indipendente o gruppo di
lotti dischi indipendenti. L'oggetto di notifica sull'altro lotto dischi indipendente o gruppo di lotti
dischi indipendenti viene aggiornato se si verifica una fine anomala della definizione di commit. Se
l'oggetto di notifica non viene trovato sull'altro lotto dischi indipendente o gruppo di lotti dischi
indipendenti, l'aggiornamento ha esito negativo con il messaggio CPF8358.
Lo spazio nome corrente del lavoro determina qual è l'IASP (Independent ASP) in cui viene creata la
definizione di commit. Se il lavoro non è associato a un IASP (Independent ASP), la definizione di
commit viene creata in *SYSBAS, altrimenti viene creata nell'IASP (Independent ASP). Se il lavoro è
associato a un IASP (Independent ASP), è possibile aprire i file sotto il controllo del commit che si
trovano nello spazio nome libreria corrente; possono trovarsi, ad esempio, nell'IASP (Independent ASP) o
in *SYSBAS. Se la prima risorsa posta sotto il controllo del commit non si trova nello stesso ASP della
definizione di commit, la definizione di commit viene spostata all'ASP della risorsa. Se sia la risorsa
*SYSBAS sia la risorsa IASP (Independent ASP) sono registrate nella stessa definizione di commit, il
sistema utilizza implicitamente un protocollo di commit in due fasi per assicurare che le risorse vengano
sottoposte a commit in modo atomico (indivisibile) se si verifica un malfunzionamento del sistema.
Pertanto, le transazioni che comportano dei dati sia in *SYSBAS sia in un IASP (Independent ASP)
avranno prestazioni inferiori alle transazioni isolate a un singolo gruppo ASP.
Considerazioni sul giornale predefinito
Sono da notare le seguenti considerazioni sul giornale predefinito:
v Se si utilizza il giornale predefinito, il giornale deve trovarsi sullo stesso lotto dischi indipendente o
gruppo di lotti dischi indipendenti della definizione di commit.
Controllo del commit
23
v Se il giornale predefinito non viene trovato sull'altro lotto dischi indipendente o gruppo di lotti dischi
indipendenti quando viene avviato il controllo del commit, l'avvio del controllo del commit ha esito
negativo con il messaggio CPF9873.
v Se si sposta la definizione di commit in un altro lotto dischi indipendente o gruppo di lotti dischi
indipendenti, anche il giornale predefinito deve trovarsi sull'altro lotto dischi indipendente o gruppo di
lotti dischi indipendenti. Se il giornale non viene trovato sull'altro lotto dischi indipendente o gruppo
di lotti dischi indipendenti, la definizione di commit viene spostata ma, da questo punto in poi, non
viene utilizzato alcun giornale predefinito.
Considerazioni su IPL (initial program load) e disattivazione
|
|
|
|
|
|
Sono da notare le seguenti considerazioni su IPL e disattivazione:
v Il ripristino di definizioni di commit che si trovano su un lotto dischi indipendente viene eseguito
durante l'elaborazione di attivazione del lotto dischi indipendente ed è simile al ripristino IPL.
v Le definizioni di commit in un lotto dischi indipendente non vengono ripristinate durante l'IPL di
sistema.
v Quando è richiesto il ripristino per una definizione di commit che contiene risorse che si trovano sia in
*SYSBAS sia in un IASP (Independent ASP), la definizione di commit verrà divisa in due definizioni di
commit durante il ripristino, una in *SYSBAS e una nell'IASP (Independent ASP), come se esistesse una
connessione a un database remoto tra i due gruppi ASP. La risincronizzazione può essere iniziata dal
sistema durante il ripristino per assicurare che i dati in entrambi i gruppi ASP siano sottoposti a
commit o a rollback in modo atomico (indivisibile).
v La disattivazione di un lotto dischi indipendente ha i seguenti effetti sulle definizioni di commit:
– I lavori associati al lotto dischi indipendente terminano.
– Non è consentita la creazione di alcuna nuova definizione di commit sul lotto dischi indipendente.
– Le definizioni di commit che si trovano sul lotto dischi indipendente diventano inutilizzabili.
– Le definizioni che si trovano sul lotto dischi indipendente, ma non collegate a un lavoro, rilasciano i
blocchi nell'ambito della transazione.
Considerazioni sui database remoti
Sono da notare le seguenti considerazioni sui database remoti:
v Non è possibile utilizzare una connessione SNA LU 6.2 (conversazioni protette o DUW (Distributed
Unit of Work - unità di lavoro distribuita) per stabilire una connessione a un database remoto da un
database di lotto dischi indipendente. È possibile utilizzare le conversazioni SNA non protette per
stabilire una connessione da un database di lotto dischi indipendente a un database remoto.
v Quando il controllo del commit è attivo per un lavoro o un sottoprocesso, l'accesso ai dati
esternamente al lotto dischi indipendente o al gruppo di lotti dischi cui appartiene la definizione di
commit è possibile solo in remoto, come se fossero dati che si trovano su un altro sistema. Quando si
emette un'istruzione SQL CONNECT per stabilire una connessione al database relazionale (RDB) sul
lotto dischi indipendente, il sistema rende remota la connessione.
v Il lotto dischi di sistema e i lotti dischi di base non richiedono una connessione remota per l'accesso in
sola lettura ai dati che si trovano su un lotto dischi indipendente. In modo analogo, un lotto dischi
indipendente non richiede una connessione remota per l'accesso in sola lettura ai dati che si trovano
sul lotto dischi di sistema o su un lotto dischi di base.
24
IBM i: Database Controllo del commit
Concetti correlati
“Definizione di commit” a pagina 5
La definizione di commit contiene informazioni pertinenti alle risorse di cui è in corso la modifica sotto il
controllo del commit durante una transazione.
“Oggetto di notifica del commit” a pagina 53
Un oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioni
che identificano l'ultima transazione eseguita correttamente completata per una specifica definizione di
commit se tale definizione di commit non è stata terminata normalmente.
“Ripristino del controllo del commit durante l'IPL (initial program load) dopo la fine anomala” a pagina
67
Quando si esegue un IPL (initial program load) dopo la fine anomala del sistema, il sistema prova a
ripristinare tutte le definizioni di commit che erano attive quando il sistema è stato terminato.
Considerazioni per le transazioni XA
Nell'ambiente XA, ciascun database viene considerato un gestore risorsa separato. Quando un gestore
transazioni desidera accedere a due database sotto la stessa transazione, deve utilizzare i protocolli XA
per eseguire un commit in due fasi con i due gestori risorse.
Poiché ciascun lotto dischi indipendente è un database SQL separato, nell'ambiente XA ciascun lotto
dischi indipendente viene considerato anche un gestore risorsa separato. Per consentire al server delle
applicazioni di eseguire una transazione destinata a due lotti dischi indipendenti differenti, il gestore
transazioni deve utilizzare anche un protocollo di commit in due fasi.
Concetti correlati
“Supporto delle transazioni XA per il controllo del commit” a pagina 46
DB2 for i può partecipare nelle transazioni globali X/Open.
Independent disk pool examples
Considerazioni e limitazioni per il controllo del commit
È necessario tenere presente le seguenti considerazioni e limitazioni per il controllo del commit.
Considerazioni sul file di database
v Se si specifica che un file condiviso venga aperto sotto il controllo del commit, tutti i successivi utilizzi
di tale file devono essere aperti sotto il controllo del commit.
v Se SEQONLY(*YES) viene specificato per il file aperto per la sola lettura con LCKLVL(*ALL)
(implicitamente o tramite un programma HLL (high-level language) oppure esplicitamente tramite il
comando OVRDBF (Sostituzione con file database)), SEQONLY(*YES) viene ignorato e viene utilizzato
SEQONLY(*NO).
v Le modifiche a livello di record apportate sotto il controllo del commit vengono registrate in un
giornale. Queste modifiche possono essere applicate al, o eliminate dal, database con il comando
APYJRNCHG (Applicazione modifiche giornale) oppure il comando RMVJRNCHG (Eliminazione
modifiche giornale).
v Sia le immagini-precedenti sia le immagini-successive dei file vengono registrate sul giornale sotto il
controllo del commit. Se si specifica di registrare sul giornale solo le immagini-successive dei file, il
sistema registra sul giornale automaticamente anche l'immagine-precedente delle modifiche al file che
si sono verificate sotto il controllo del commit. Tuttavia, poiché le immagini-precedenti non vengono
catturate per tutte le modifiche apportate ai file, non è possibile utilizzare il comando RMVJRNCHG
per questi file.
Considerazioni per le modifiche a livello di oggetto e a livello di record
v Le modifiche a livello di oggetto e a livello di record eseguite sotto il controllo del commit utilizzando
SQL utilizzano la definizione di commit attualmente attiva per il gruppo di attivazione in cui è in
Controllo del commit
25
esecuzione il programma richiedente. Se non è attiva né la definizione di commit a livello di lavoro né
quella a livello di gruppo di attivazione, SQL avvierà una definizione di commit a livello di gruppo di
attivazione.
Considerazioni sul commit in una fase e in due fasi
v Mentre è stabilita una connessione o una conversazione remota in una fase, le connessioni o le
conversazioni remote ad altre ubicazioni non sono consentite. Se è stabilito un limite di commit e
vengono eliminate tutte le risorse, l'ubicazione può essere modificata.
v Se si sta utilizzando il commit in due fasi, non è necessario utilizzare il comando SBMRMTCMD
(Immissione comando remoto) per avviare il controllo del commit o eseguire eventuali altre operazioni
di controllo del commit sulle ubicazioni remote. Il sistema esegue queste funzioni per conto dell'utente.
v Per un'ubicazione remota in una fase, i comandi CL COMMIT e ROLLBACK avranno esito negativo se
SQL si trova nello stack di chiamata e il database relazionale remoto non si trova su un sistema. Se
SQL non si trova nello stack di chiamata, i comandi COMMIT e ROLLBACK non avranno esito
negativo.
v Per un'ubicazione remota in una fase, il controllo del commit deve essere avviato sul sistema di origine
prima di apportare delle modifiche di cui è possibile eseguire il commit alle risorse remote. Il sistema
avvia automaticamente il controllo del commit per l'SQL di database distribuito sul sistema di origine
in fase di connessione se il programma SQL è in esecuzione con l'opzione di controllo del commit
impostata su un valore diverso da *NONE. Quando la prima risorsa remota viene posta sotto il
controllo del commit, il sistema avvia il controllo del commit sul sistema di destinazione.
Considerazione sul salvataggio
Un'operazione di salvataggio non è consentita se il lavoro che esegue il salvataggio ha una o più
definizioni di commit attive con uno qualsiasi dei seguenti tipi di modifiche di cui è possibile eseguire il
commit:
v Una modifica di record a un file che si trova nella libreria di cui si sta eseguendo il salvataggio. Per i
file logici, vengono controllati tutti i file fisici correlati.
v Qualsiasi modifica a livello di oggetto in una libreria di cui si sta eseguendo il salvataggio.
v Qualsiasi risorsa API che è stata aggiunta utilizzando l'API QTNADDCR (Aggiunta risorsa di commit)
e con il campo che indica che è consentita la normale elaborazione di salvataggio impostato sul valore
predefinito di N.
Questo impedisce alle operazioni di salvataggio di salvare sul supporto di salvataggio le modifiche
dovute a una transazione parziale.
Nota: se si utilizza il nuovo salvataggio con la funzione di transazioni parziali, l'oggetto può essere
salvato senza terminare una definizione di commit.
I blocchi di oggetti e i blocchi di record impediscono il salvataggio sul supporto di salvataggio
delle modifiche in sospeso dalle definizioni di commit in altri lavori. Questo è vero solo per le
risorse di commit API se i blocchi vengono acquisiti quando vengono apportate delle modifiche
all'oggetto o agli oggetti associati alla risorsa di commit API.
Considerazioni e limitazioni varie
v Prima di aggiornare il sistema a una nuova release, tutte le risincronizzazioni in sospeso devono essere
completate o annullate.
v I valori COMMIT e ROLLBACK vengono visualizzati nel campo relativo alla funzione di WRKACTJOB
durante un commit o un rollback. Se tale funzione rimane COMMIT o ROLLBACK per molto tempo, è
possibile che si sia verificato uno dei seguenti eventi:
– Un errore di risorsa durante il commit o il rollback richiede la risincronizzazione. Il controllo non
ritornerà all'applicazione finché la risincronizzazione non sarà stata completata o annullata.
26
IBM i: Database Controllo del commit
– Questo sistema ha indicato la decisione VRO (vote read-only) durante il commit. Il controllo non
ritornerà all'applicazione finché il sistema che ha iniziato il commit non avrà inviato i dati a questo
sistema.
– Questo sistema ha indicato che era OK tralasciare durante il commit. Il controllo non ritornerà
all'applicazione finché il sistema che ha iniziato il commit non invierà i dati a questo sistema.
Concetti correlati
Assicurazione dell'integrità del commit in due fasi
“Livello di blocco del commit” a pagina 55
Il valore specificato per il parametro LCKLVL nel comando STRCMTCTL (Avvio controllo commit)
diventa il livello predefinito di blocco di record per i file di database aperti e posti sotto il controllo del
commit per la definizione di commit.
Riferimenti correlati
Override with Database File (OVRDBF) command
Apply Journaled Changes (APYJRNCHG) command
Remove Journaled Changes (RMVJRNCHG) command
SQL programming
Submit Remote Command (SBMRMTCMD) command
Commit (COMMIT) command
Rollback (ROLLBACK) command
Add Commitment Resource (QTNADDCR) API
Controllo del commit per le applicazioni batch
Le applicazioni batch possono richiedere o meno il controllo del commit. In alcuni casi, un'applicazione
batch può eseguire una singola funzione di lettura di un file di immissione e di aggiornamento di un file
master. Tuttavia, è possibile utilizzare il controllo del commit per questo tipo di applicazione se è
importante avviarla nuovamente dopo una fine anomala.
Il file di immissione è un file di aggiornamento con un codice nei record per indicare che è stato
elaborato un record. Questo file e gli eventuali file aggiornati vengono posti sotto il controllo del commit.
Quando è presente nel file di immissione, il codice rappresenta una transazione completata. Il programma
legge il file di immissione e tralascia i record con un codice di completato. Questo consente l'utilizzo della
stessa logica di programma per le condizioni normali e di riavvio.
Se l'applicazione batch contiene dei record di immissione interdipendenti e contiene commutazioni o
totali, è possibile utilizzare un oggetto di notifica per fornire informazioni sul riavvio. I valori conservati
nell'oggetto di notifica vengono utilizzati per riavviare l'elaborazione dall'ultima transazione di cui è stato
eseguito il commit nel file di immissione.
|
|
|
|
|
|
|
|
|
|
|
|
Se i record di immissione sono interdipendenti, possono essere elaborati come una transazione. Un lavoro
batch può bloccare un massimo di 500 000 000 record. È possibile ridurre questo limite utilizzando un file
delle opzioni query (QAQQINI). Utilizzare il parametro QRYOPTLIB del comando CHGQRYA (Modifica
attributi query) per specificare un file delle opzioni query che può essere utilizzato da un lavoro.
Utilizzare il valore COMMITMENT_CONTROL_LOCK_LEVEL nel file delle opzioni query come limite di
blocco per il lavoro. Il valore del limite di blocco viene memorizzato internamente nella cache per
ciascuna definizione di commit la prima volta che una risorsa registrata su giornale viene posta sotto il
controllo del commit. Se il limite di blocco viene modificato dopo tale punto, il valore memorizzato nella
cache deve essere aggiornato perché diventi effettivo per tale definizione di commit. Qualsiasi chiamata
dell'API di richiamo di informazioni di commit QTNRCMTI aggiorna il valore memorizzato nella cache
nel lavoro chiamante. Il nuovo valore non si applicherà alle transazioni avviate prima dell'aggiornamento
della cache.
Controllo del commit
27
Eventuali cicli di commit che superano i 2000 blocchi probabilmente rallentano notevolmente le
prestazioni del sistema. Altrimenti, si applicano le stesse considerazioni di blocco valide per le
applicazioni interattive ma il lasso di tempo per cui i record sono bloccati in un'applicazione batch
potrebbe essere meno importante che nelle applicazioni interattive.
Concetti correlati
“Oggetto di notifica del commit” a pagina 53
Un oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioni
che identificano l'ultima transazione eseguita correttamente completata per una specifica definizione di
commit se tale definizione di commit non è stata terminata normalmente.
“Gestione della dimensione della transazione” a pagina 75
Un altro modo per ridurre al minimo i blocchi di record consiste nel gestire la dimensione della
transazione.
Riferimenti correlati
Change Query Attributes (CHGQRYA) command
Controllo del commit in due fasi
Il controllo del commit in due fasi assicura che le risorse di cui è possibile eseguire il commit su più
sistemi rimangano sincronizzate.
Il sistema operativo i5/OS supporta il commit in due fasi in base all'architettura SNA LU 6.2. Per
informazioni più dettagliate sui protocolli interni utilizzati dal sistema per il commit in due fasi,
consultare il manuale SNA Transaction Programmer's Reference for LU Type 6.2, GC30-3084-05. Tutte le
release supportate del sistema operativo i5/OS supportano i protocolli Presumed Nothing di SNA LU 6.2
e i protocolli Presumed Abort di SNA LU 6.2.
Il commit in due fasi è supportato anche utilizzando TCP/IP come una protocollo DUW (Distributed
Unit of Work - unità di lavoro distribuita) DRDA (Distributed Relational Database Architecture). Per
utilizzare le connessioni DUW TCP/IP, tutti i sistemi (sia il richiedente dell'applicazione che il server
delle applicazioni) devono essere alla V5R1M0 o successive. Per ulteriori informazioni su DRDA,
consultare l'Open Group Technical Standard, DRDA V2 Vol. 1: Distributed Relational Database Architecture
sul sito Web di The Open Group.
Sotto il commit in due fasi, il sistema esegue l'operazione di commit in due fasi:
v Durante la fase di preparazione, un gestore risorse emette una richiesta di commit al suo gestore
transazioni. Il gestore transazioni informa le altre risorse che gestisce e gli altri gestori transazioni che
la transazione è pronta per essere sottoposta a commit. Tutti i gestori risorse devono rispondere che
sono pronti ad eseguire il commit. Questa è detta decisione.
v Durante la fase di commit, il gestore transazioni che inizia la richiesta di commit decide cosa fare, in
base all'esito della fase di preparazione. Se la fase di preparazione viene completata correttamente e
tutti i partecipanti decidono che sono pronti, il gestore transazioni può indicare a tutte le risorse che
gestisce a agli altri gestori transazioni di eseguire il commit della transazione. Se la fase di
preparazione non viene completata correttamente, a tutti i gestori transazioni e a tutti i gestori risorse
viene indicato di eseguire il rollback della transazione.
Operazioni di commit e rollback con le risorse remote
Quando le risorse remote sono sotto il controllo del commit, l'iniziatore invia una richiesta di commit a
tutti gli agent remoti. La richiesta viene inviata in tutta la rete del programma di transazione. Ciascun
agent risponde con i risultati dell'operazione di commit.
Se si verificano degli errori durante la fase di preparazione, l'iniziatore invia una richiesta di rollback a
tutti gli agent. Se si verificano degli errori durante la fase di commit, il sistema prova a portare il maggior
28
IBM i: Database Controllo del commit
numero di ubicazioni possibile allo stato di sottoposto a commit. Questi tentativi potrebbero determinare
uno stato misto euristico. Consultare la sezione Stati della transazione per il controllo del commit in due
fasi per ulteriori informazioni sugli stati possibili.
Eventuali errori vengono restituiti all'iniziatore dove vengono segnalati all'utente. Se è stato specificato un
giornale predefinito nel comando STRCMTCTL (Avvio controllo commit), vengono scritte le voci C LW.
Se si verificano degli errori, queste voci vengono scritte anche se è stato specificato OMTJRNE(*LUWID).
È possibile utilizzare queste voci, insieme ai messaggi di errore e alle informazioni sullo stato per la
definizione di commit, per provare a sincronizzare manualmente le risorse di cui è possibile eseguire il
commit.
Quando le risorse remote sono sotto il controllo del commit, l'iniziatore invia una richiesta di rollback a
tutti gli agent remoti. La richiesta viene inviata in tutta la rete del programma di transazione. Ciascun
agent risponde con i risultati dell'operazione di rollback.
Concetti correlati
The Open Group Web site
Riferimenti correlati
Start Commitment Control (STRCMTCTL) command
Ruoli nell'elaborazione di commit
Se un commit di una transazione interessa più di un gestore risorse, ciascun gestore risorse ha un ruolo
nella transazione. Un gestore risorse è responsabile per il commit o il rollback delle modifiche apportate
durante la transazione.
I gestori risorse per tipo di risorsa sono i seguenti:
FILE
Database manager
DDM Database manager
DDL
Database manager
DRDA
Programma di transazioni relative alle comunicazioni
LU62
Programma di transazioni relative alle comunicazioni
API
Programma di uscita API
Le seguenti figure mostrano i ruoli di base in una transazione. La struttura mostrata nelle figure è detta
rete programma di transazione. La struttura può trovarsi in un albero a livello singolo e in un albero a più
livelli.
Ruoli nell'elaborazione di commit in due fasi: albero a livello singolo
Quando un'applicazione sul Sistema A emette una richiesta di commit, il gestore risorse sul Sistema A
diventa l'iniziatore. Per l'unità di lavoro distribuita DRDA (Distributed Relational Database Architecture)
su TCP/IP, l'iniziatore viene detto coordinatore.
I gestori risorse per gli altri tre sistemi (B, C e D) diventano agent per questa transazione. Per l'unità di
lavoro distribuita DRDA su TCP/IP, gli agent sono a volte detti partecipanti.
Controllo del commit
29
Ruoli nell'elaborazione di commit in due fasi: albero a più livelli
Se l'applicazione sta utilizzando le comunicazioni APPC per eseguire il commit in due fasi, la relazione
tra i sistemi può cambiare da una transazione alla successiva. La seguente figura mostra gli stessi sistemi
quando un'applicazione sul Sistema B emette la richiesta di commit. Questa configurazione è un albero a
più livelli.
I ruoli in questa figura non sono validi per l'unità di lavoro distribuita DRDA su TCP/IP perché gli alberi
di transazioni a più livelli non sono supportati.
30
IBM i: Database Controllo del commit
La rete del programma di transazione ha un altro livello perché il Sistema B non sta comunicando
direttamente con il Sistema C e il Sistema D. Il gestore risorse nel Sistema A ora ha i ruoli di agent e
iniziatore a cascata.
Per migliorare le prestazioni delle transazioni in due fasi LU 6.2, l'iniziatore può assegnare il ruolo di
ultimo agent a uno degli agent. L'ultimo agent non partecipa alla fase di preparazione. Nella fase di
commit, l'ultimo agent esegue il commit per primo. Se il commit dell'ultimo agent non viene eseguito
correttamente, l'iniziatore indica agli altri agent di eseguire il rollback.
Per l'unità di lavoro distribuita DRDA su TCP/IP, il coordinatore può assegnare il ruolo di server di
risincronizzazione a un partecipante. Il server di risincronizzazione è responsabile per la
risincronizzazione degli altri partecipanti se si verifica un errore nelle comunicazioni con il coordinatore o
se si verifica un errore di sistema per il coordinatore.
Concetti correlati
“Definizione di commit per un commit in due fasi: consentire VRO (vote read-only)” a pagina 35
Di norma, un gestore transazioni partecipa a entrambe le fasi dell'elaborazione di commit. Per migliorare
le prestazioni dell'elaborazione di commit, è possibile configurare qualcuna delle ubicazioni, oppure tutte,
in una transazione per consentire al gestore transazioni di eseguire il VRO (vote read-only).
Stati della transazione per il controllo del commit a due fasi
Una definizione di commit viene stabilita su ciascuna ubicazione che fa parte della rete del programma di
transazione. Per ciascuna definizione di commit, il sistema tiene traccia dello stato della sua transazione
corrente e della transazione precedente.
Controllo del commit
31
Il sistema utilizza lo stato per decidere se eseguire il commit o il rollback se una transazione viene
interrotta da un errore di sistema o nelle comunicazioni. Se più ubicazioni stanno partecipando a una
transazione, gli stati delle transazioni su ciascuna ubicazione potrebbero essere messi a confronto per
determinare l'azione corretta (commit o rollback). Il processo di comunicazione tra le ubicazioni per
determinare l'azione corretta è detto risincronizzazione.
La seguente tabella mostra questi elementi:
v Gli stati di base che possono verificarsi durante una transazione.
v Gli stati aggiuntivi che possono verificarsi.
v Se uno stato richiede la risincronizzazione se la transazione viene interrotta da un errore di sistema o
nelle comunicazioni. I valori possibili sono i seguenti:
Non richiesto
Ciascuna ubicazione può prendere la decisione corretta indipendentemente.
Può essere necessario
Ciascuna ubicazione può prendere la decisione corretta, ma l'iniziatore potrebbe richiedere di
essere informato della decisione.
Richiesto
Lo stato di ciascuna ubicazione deve essere determinato prima che possa essere presa la
decisione corretta.
v Azione eseguita da un errore di sistema o nelle comunicazioni.
Nome stato
Descrizione
Risincronizzazione se la
transazione viene
interrotta
Azione eseguita da un
errore di sistema o nelle
comunicazioni
Stati di base durante l'elaborazione di commit in due fasi:
Ripristinare (RST)
Dal limite di commit fino a
quando il programma
emette una richiesta di
commit o di rollback.
Non necessario.
Viene eseguito il rollback
delle modifiche in sospeso.
Preparazione in corso (PIP)
L'iniziatore ha avviato la
fase di preparazione. Tutte
le ubicazioni non hanno
ancora indicato la loro
decisione.
Potrebbe essere necessaria.
Viene eseguito il rollback
delle modifiche in sospeso.
Preparato (PRP)
Questa ubicazione e tutte le Richiesta.
ubicazioni più in basso
nella rete del programma di
transazione hanno deciso
per il commit. Questa
ubicazione non ha ancora
ricevuto la notifica
dall'iniziatore di eseguire il
commit.
In dubbio. Dipende dai
risultati del processo di
risincronizzazione.
Commit in corso (CIP)
Tutte le ubicazioni hanno
deciso per il commit.
L'iniziatore ha avviato la
fase di commit.
Le modifiche in sospeso
vengono sottoposte a
commit. Viene eseguita la
risincronizzazione per
assicurare che tutte le
ubicazioni abbiano eseguito
il commit. Se viene
notificato un rollback
euristico da un'altra
ubicazione, viene notificato
un errore.
32
IBM i: Database Controllo del commit
Richiesta.
Nome stato
Descrizione
Sottoposto a commit (CMT) Tutti gli agent hanno
eseguito il commit e
restituito una risposta a
questo nodo.
Risincronizzazione se la
transazione viene
interrotta
Azione eseguita da un
errore di sistema o nelle
comunicazioni
Potrebbe essere necessaria.
Nessuna.
Stati aggiuntivi durante l'elaborazione di commit in due fasi:
Ultimo agent in sospeso
(LAP)
Richiesta.
Se viene selezionato un
ultimo agent, questo stato
si verifica presso l'iniziatore
tra lo stato PIP e lo stato
CIP. L'iniziatore ha dato
istruzione all'ultimo agent
di eseguire il commit e non
ha ancora ricevuto una
risposta.
In dubbio. Dipende dai
risultati del processo di
risincronizzazione.
Vote-Read-Only (VRO)
Questo agent ha risposto
alla fase di preparazione
indicando che non ha
modifiche in sospeso. Se è
consentito lo stato VRO
(vote read-only), questo
agent non viene incluso
nella fase di commit.
Potrebbe essere necessaria.
Nessuna.
Rollback richiesto (RBR)
Si è verificato uno dei
seguenti eventi:
Potrebbe essere necessaria.
Viene eseguito il rollback
delle modifiche in sospeso.
v Un agent ha emesso una
richiesta di rollback
prima dell'operazione di
commit.
v Si è verificato un errore
di transazione.
v L'API QTNRBRQD è
stata utilizzata per
mettere la transazione in
uno stato di rollback
richiesto.
Al programma di
transazione non è
consentito eseguire ulteriori
modifiche sotto il controllo
del commit.
Condizioni che si verificano a causa di errori o di azioni dell'operatore:
Rollback forzato
Questa ubicazione e tutte le Potrebbe essere necessaria.
ubicazioni più in basso
nella rete del programma di
transazione, tranne l'ultimo
agent, sono state sottoposte
a rollback per intervento
dell'operatore.
Le modifiche in sospeso
sono già state sottoposte a
rollback.
Controllo del commit
33
Risincronizzazione se la
transazione viene
interrotta
Azione eseguita da un
errore di sistema o nelle
comunicazioni
Nome stato
Descrizione
Commit forzato
Questa ubicazione e tutte le Potrebbe essere necessaria.
ubicazioni più in basso
nella rete del programma di
transazione, tranne l'ultimo
agent, sono state sottoposte
a commit per intervento
dell'operatore.
Le modifiche in sospeso
sono già state sottoposte a
commit.
Euristico misto (HRM)
Alcuni gestori risorse
hanno eseguito il commit.
Alcuni hanno eseguito il
rollback. È stato utilizzato
l'intervento dell'operatore
oppure si è verificato un
errore di sistema. Euristico
misto non compare come
uno stato sulle
visualizzazioni delle
definizioni di commit. Dei
messaggi di notifica
vengono inviati
all'operatore.
Potrebbe essere necessaria.
L'operatore deve eseguire
un'operazione di ripristino
su tutte le ubicazioni
partecipanti per portare il
database a uno stato
congruente.
Concetti correlati
“Definizione di commit per un commit in due fasi: consentire VRO (vote read-only)” a pagina 35
Di norma, un gestore transazioni partecipa a entrambe le fasi dell'elaborazione di commit. Per migliorare
le prestazioni dell'elaborazione di commit, è possibile configurare qualcuna delle ubicazioni, oppure tutte,
in una transazione per consentire al gestore transazioni di eseguire il VRO (vote read-only).
“Definizione di commit per un commit in due fasi: Non attendere risultato” a pagina 37
Quando si verifica un malfunzionamento nelle comunicazioni o di sistema durante un'operazione di
commit, ed è quindi richiesta una risincronizzazione, il valore predefinito prevede di attendere che la
risincronizzazione sia terminata prima di completare l'operazione di commit.
“Avvio del controllo del commit” a pagina 52
Per avviare il controllo del commit, utilizzare il comando STRCMTCTL (Avvio controllo commit).
“Ripristino del controllo del commit durante l'IPL (initial program load) dopo la fine anomala” a pagina
67
Quando si esegue un IPL (initial program load) dopo la fine anomala del sistema, il sistema prova a
ripristinare tutte le definizioni di commit che erano attive quando il sistema è stato terminato.
“Errori del controllo del commit” a pagina 107
Quando si utilizza il controllo del commit, è importante comprendere quali condizioni causano degli
errori e quali no.
Definizioni di commit per il controllo del commit in due fasi
Per modificare le opzioni di commit per la transazione dopo l'avvio del controllo del commit, utilizzare
l'API QTNCHGCO (Modifica opzioni di commit).
In base all'ambiente utilizzato e alle applicazioni utilizzate, la modifica delle opzioni di commit può
migliorare le prestazioni del sistema.
Nota: se si sta utilizzando un'unità di lavoro distribuita DRDA su una connessione TCP/IP, la sola
opzione valida è quella che consente VRO (vote read-only).
34
IBM i: Database Controllo del commit
Riferimenti correlati
Change Commitment Options (QTNCHGCO) API
Definizione di commit per un commit in due fasi: consentire VRO (vote read-only):
Di norma, un gestore transazioni partecipa a entrambe le fasi dell'elaborazione di commit. Per migliorare
le prestazioni dell'elaborazione di commit, è possibile configurare qualcuna delle ubicazioni, oppure tutte,
in una transazione per consentire al gestore transazioni di eseguire il VRO (vote read-only).
Se l'ubicazione non ha modifiche di cui è possibile eseguire il commit durante una transazione, il gestore
transazioni esegue il VRO (vote read-only) durante la fase di preparazione. L'ubicazione non partecipa
alla fase di commit. Questo migliora le prestazioni generali perché i flussi di comunicazioni che di norma
si verificano durante la fase di commit vengono eliminati durante le transazioni in cui non viene eseguito
alcun aggiornamento su una o più ubicazioni remote.
Dopo aver avviato il controllo del commit, è possibile utilizzare l'API QTNCHGCO (Modifica opzioni di
commit) per modificare l'opzione VRO (Vote read only) consentito in Y. È possibile eseguire questa
operazione se ricorrono le seguenti condizioni:
v Spesso uno o più sistemi remoti non hanno alcuna modifica di cui è possibile eseguire il commit per
una transazione.
v Una transazione non dipende da dove il cursore del file (record successivo) è stato impostato dalla
transazione precedente. Quando un'ubicazione dà un'indicazione di VRO (vote read-only),
l'applicazione non viene mai informata se viene eseguito il rollback della transazione. L'ubicazione ha
eseguito il commit delle operazioni di lettura con i file del database e, pertanto, ha spostato la
posizione del cursore. La posizione del cursore del file è di norma importante solo se si esegue
un'elaborazione sequenziale.
Se la definizione di commit è impostata per consentire VRO (vote read-only), l'applicazione attende il
successivo flusso di messaggi da un'altra ubicazione.
L'opzione VRO (Vote read only) consentito è progettata per le applicazioni con una natura client/server.
Se il solo scopo del programma A è soddisfare le richieste dal programma I e non di eseguire del lavoro
indipendente, è appropriato consentire l'opzione VRO (vote read-only) per il programma A.
Flusso di elaborazione di commit senza l'ottimizzazione di ultimo agent quando l'agent dà
un'indicazione di VRO (vote read-only)
La seguente figura mostra il flusso di messaggi tra i programmi applicativi e i gestori transazioni quando
un programma applicativo emette un'istruzione di commit senza l'ottimizzazione di ultimo agent quando
l'agent dà come indicazione VRO (vote read-only). Né il programma applicativo iniziatore né i
programmi applicativi agent rilevano l'elaborazione di commit in due fasi. I numeri tra parentesi () nella
figura corrispondono agli elementi numerati nella descrizione successiva.
Controllo del commit
35
Il seguente elenco è una descrizione degli eventi per l'elaborazione normale senza l'ottimizzazione di
ultimo agent quando l'agent dà l'indicazione di VRO (vote read-only). È rappresentata la descrizione di
un flusso di base. La sequenza di eventi può diventare molto più complessa quando la rete del
programma di transazione ha più livelli o quando si verificano degli errori.
1. Il programma applicativo A esegue un'operazione di ricezione richiesta per indicare che è pronto a
ricevere una richiesta dal programma I.
2. L'applicazione iniziatore (I) emette un'istruzione di commit.
3. Il gestore transazioni per l'iniziatore (TM-I) assume il ruolo di iniziatore per questa transazione. Avvia
la fase di preparazione inviando un messaggio di preparazione a tutte le altre ubicazioni che stanno
partecipando alla transazione.
4. I gestori transazioni per tutte le altre ubicazioni assumono il ruolo di agent (TM-A). Il programma
applicativo A viene informato da TM-A che è stata ricevuta una richiesta di commit. Per i file ICF, la
notifica consiste nell'impostazione come attivo dell'indicatore ICF di ricezione di un'esecuzione di
commit (RCVTKCMT).
5. Il programma applicativo A risponde immettendo un'istruzione di commit (o un'istruzione di
rollback). Questa è la decisione del programma applicativo.
6. Se il programma applicativo A ha utilizzato l'API QTNCHGCO (Modifica opzioni di commit) per
impostare l'opzione di commit VRO (Vote read only) consentito su Y e non è stata apportata alcuna
modifica all'agent durante la transazione, l'agent (TM-A) risponde all'iniziatore (TM-I) con un
messaggio di reimpostazione. Non c'è alcuna fase di commit per l'agent.
7. Una restituzione viene inviata al programma applicativo (A) per indicare che la transazione è
completa presso l'agent TM-A.
8. La volta successiva che l'iniziatore (TM-I) invia un messaggio all'agent (TM-A), sia esso un flusso di
dati o un'istruzione di commit, TM-I fa in modo che il suo ID transazione corrente venga inviato con
il messaggio. Questo è dovuto al fatto che un nuovo ID transazione potrebbe essere stato generato
presso il TM-I se si era verificato un errore nelle comunicazioni tra il TM-I e un altro sistema durante
l'operazione di commit.
36
IBM i: Database Controllo del commit
9. Una restituzione viene inviata al programma applicativo (A) per indicare che la transazione è
completa presso l'agent TM-A. La restituzione viene ritardata fino a dopo la ricezione del successivo
messaggio perché il TM-I deve ricevere un nuovo ID transazione prima che l'applicazione A possa
avviare la successiva transazione.
Concetti correlati
“Ruoli nell'elaborazione di commit” a pagina 29
Se un commit di una transazione interessa più di un gestore risorse, ciascun gestore risorse ha un ruolo
nella transazione. Un gestore risorse è responsabile per il commit o il rollback delle modifiche apportate
durante la transazione.
“Stati della transazione per il controllo del commit a due fasi” a pagina 31
Una definizione di commit viene stabilita su ciascuna ubicazione che fa parte della rete del programma di
transazione. Per ciascuna definizione di commit, il sistema tiene traccia dello stato della sua transazione
corrente e della transazione precedente.
“Ottimizzazione delle prestazioni per il controllo del commit” a pagina 71
L'utilizzo del controllo del commit richiede delle risorse che possono influenzare le prestazioni del
sistema. Diversi fattori influenzano le prestazioni del sistema relativamente al controllo del commit.
Riferimenti correlati
Change Commitment Options (QTNCHGCO) API
Definizione di commit per un commit in due fasi: Non attendere risultato:
Quando si verifica un malfunzionamento nelle comunicazioni o di sistema durante un'operazione di
commit, ed è quindi richiesta una risincronizzazione, il valore predefinito prevede di attendere che la
risincronizzazione sia terminata prima di completare l'operazione di commit.
Nota: l'opzione Non attendere risultato non si applica se si sta utilizzando un'unità di lavoro distribuita
DRDA (Distributed Relational Database Architecture) su una connessione TCP/IP. L'unità di lavoro
distribuita DRDA su connessioni TCP/IP non attende mai il risultato.
Prendere in considerazione la possibilità di modificare questa modalità di funzionamento se ricorrono le
seguenti condizioni:
v Le applicazioni che partecipano sono indipendenti l'una dall'altra.
v La logica di programma non richiede i risultati delle transazioni precedenti per assicurare che i file di
database rimangano sincronizzati.
Dopo aver avviato il controllo del commit, è possibile utilizzare l'API QTNCHGCO (Modifica opzioni di
commit) per specificare che la definizione di commit non attende il risultato della risincronizzazione. Se si
specifica N (No) per l'opzione Attesa risultato, il sistema utilizza un lavoro del server di database
(QDBSRVnn) per gestire la risincronizzazione in modo asincrono.
Nota: questi lavori del server di database vengono avviati durante il processo IPL (initial program load caricamento iniziale di programma). L'eventuale modifica delle opzioni per il controllo del commit
non influenza il numero di lavori avviato dal sistema.
Questo argomento fa riferimento solo ai due valori per l'opzione Attesa risultato risolta, Y (Sì) e N
(No). Ci sono effettivamente altri due valori che è possibile specificare, L (Sì o Eredita da iniziatore) e U
(No o Eredita da iniziatore). Quando si utilizzano questi valori, il valore effettivo utilizzato durante
ciascuna operazione di commit viene risolto in Sì o No dal sistema. L'argomento relativo all'API
QTNCHGCO (Modifica opzioni di commit) contiene maggiori dettagli su questi valori.
Nota: il valore dell'iniziatore può essere ereditato solo da un agent se sia l'iniziatore sia l'agent
supportano la presunta fine anomala.
Controllo del commit
37
L'opzione WFO (wait for outcome, ossia attendere risultato) non influenza la normale elaborazione di
commit che non presenta errori. Se si verifica un errore, l'opzione WFO determina se l'applicazione
attende la risincronizzazione o meno, con le seguenti condizioni:
v Se l'opzione WFO risolta è Y (Sì), l'applicazione attende il risultato della risincronizzazione.
v Se l'opzione WFO risolta è N (No) e si verifica un errore nelle comunicazioni durante la fase di
preparazione o il rollback di un'ubicazione che supporta i protocolli di presunta fine anomala, non
viene eseguita alcuna risincronizzazione e la definizione di commit viene sottoposta a rollback.
v Se la definizione di commit è in dubbio (lo stato della transazione è Preparato o Ultimo agent in
sospeso), l'applicazione attenderà il risultato della risincronizzazione indipendentemente dal valore
dell'opzione WFO risolta.
v Se l'opzione WFO risolta è N e non ricorre né la condizione due né quella tre, il sistema prova ad
eseguire la risincronizzazione una sola volta. Se l'operazione non viene eseguita con esito positivo, il
sistema segnala il messaggio di STATO CPF83E6 all'applicazione per indicare che la risincronizzazione
è in corso.
Poiché CPF83E6 è un messaggio di STATO, ha un effetto solo se l'applicazione ne sta monitorando
l'emissione. Di norma, l'applicazione può elaborare questo messaggio come un messaggio informativo.
I sistemi che stanno partecipando al tentativo di transazione provano a risincronizzare la transazione
finché l'errore non viene corretto. Questi tentativi di risincronizzazione successivi vengono eseguiti nei
lavori del server di database. Se un successivo tentativo di risincronizzazione eseguito in un lavoro del
server di database ha esito negativo, il messaggio CPI83D0 viene inviato a QSYSOPR.
Valore di Attendi risultato: Sì
Nella seguente figura, la definizione di commit per l'iniziatore (I) utilizza il valore predefinito di Y (Sì)
per l'opzione Attendi risultato. Quando le comunicazioni tra TM-I e TM-A si interrompono, sia
l'applicazione A sia l'applicazione I attendono che la transazione venga risincronizzata.
38
IBM i: Database Controllo del commit
Valore di Attendi risultato: No
Nella seguente figura, la definizione di commit per l'iniziatore ha l'opzione WFO risolta impostata su N
(No). TM-A soddisfa la condizione 3 nell'elenco precedente, mentre TM-I soddisfa la condizione 4. Il
controllo viene restituito all'applicazione I dopo un tentativo di risincronizzazione con TM-A. Un lavoro
del server di database prova ad eseguire la risincronizzazione. L'applicazione I non riceve mai l'indicatore
di restituzione dopo il corretto completamento della richiesta di commit. Il controllo viene restituito
all'applicazione agent (A) solo dopo che le comunicazioni sono state ristabilite. Questo dipende da
quando si verifica l'errore. In questo caso, l'errore nelle comunicazioni si verifica prima che l'iniziatore
riceva il messaggio di commit, lasciando TM-A in dubbio se eseguire il commit o il rollback. Quando è in
dubbio, il gestore transazioni conserva il controllo finché la risincronizzazione non viene completata,
indipendentemente dal valore dell'opzione WFO risolta per tale sistema.
Se si desidera che le applicazioni su tutti i sistemi continuino prima che venga completata la
risincronizzazione, è necessario modificare l'opzione WFO risolta in N (No) su tutti i sistemi oppure
impostare l'iniziatore su N e il resto dei sistemi su U (No o Eredita da iniziatore). Tenere tuttavia presente
che l'opzione WFO risolta viene ignorata quando il gestore transazioni è in dubbio se eseguire il commit
o il rollback e attende sempre che la risincronizzazione venga completata prima di restituire il controllo.
Controllo del commit
39
Quando viene stabilita una connessione a un database relazionale remoto, e non sono già state avviate
delle conversazioni protette, il sistema modifica in modo implicito il valore Attendi risultato in N.
Questo è dovuto al fatto che le prestazioni delle operazioni di commit sono migliori quando il valore
Attendi risultato è N e il sistema remoto supporta la presunta fine anomala. Questa modifica implicita
del valore Attendi risultato viene eseguita solo per le applicazioni DDM e DRDA. Le applicazioni
APPC utilizzano il valore predefinito Attendi risultato di Y a meno che non richiamino l'API
QTNCHGCO per modificarlo.
40
IBM i: Database Controllo del commit
Concetti correlati
“Stati della transazione per il controllo del commit a due fasi” a pagina 31
Una definizione di commit viene stabilita su ciascuna ubicazione che fa parte della rete del programma di
transazione. Per ciascuna definizione di commit, il sistema tiene traccia dello stato della sua transazione
corrente e della transazione precedente.
“Errori del controllo del commit” a pagina 107
Quando si utilizza il controllo del commit, è importante comprendere quali condizioni causano degli
errori e quali no.
Riferimenti correlati
Change Commitment Options (QTNCHGCO) API
Definizione di commit per un commit in due fasi: indicazione di OK tralasciare:
Di norma, il gestore transazioni in qualsiasi ubicazione nella rete del programma di transazione partecipa
a ogni operazione di commit o di rollback. Per migliorare le prestazioni, è possibile configurare qualcuna
o tutte le ubicazioni in una transazione per consentire al gestore transazioni di indicare che è OK
tralasciare.
Nota: l'opzione OK tralasciare non si applica se si sta utilizzando un'unità di lavoro distribuita DRDA
sulla connessione TCP/IP.
Se nessun flusso di comunicazioni viene inviato all'ubicazione durante una transazione, l'ubicazione viene
omessa quando viene eseguita un'operazione di commit o di rollback. Questo migliora le prestazioni
generali perché i flussi di comunicazioni che di norma si verificano durante il commit o il rollback
vengono eliminati durante le transazioni in cui nessun dato viene inviato a una o più ubicazioni remote.
Dopo aver avviato il controllo del commit, è possibile utilizzare l'API QTNCHGCO (Modifica opzioni di
commit) per modificare l'opzione OK tralasciare in Y (Sì). È possibile eseguire questa operazione se uno o
più sistemi remoti spesso non sono coinvolti in una transazione.
Se la definizione di commit è configurata per indicare che è OK tralasciare, l'applicazione attende il
successivo flusso di messaggi da un'altra ubicazione.
L'opzione che indica che è OK tralasciare è progettata per le applicazioni con una natura client/server. Se
il solo scopo del programma A è soddisfare le richieste dal programma I e non di eseguire del lavoro
indipendente, è appropriato consentire l'opzione che indica che è OK tralasciare per il programma A.
Flusso di elaborazione di commit senza l'ottimizzazione di ultimo agent quando l'agent dà
un'indicazione di OK tralasciare
La seguente figura mostra il flusso di messaggi tra i programmi applicativi e i gestori transazioni quando
un programma applicativo emette un'istruzione di commit senza l'ottimizzazione di ultimo agent quando
l'agent dà come indicazione OK tralasciare. Sia il programma applicativo iniziatore sia i programmi
applicativi agent non rilevano l'elaborazione di commit in due fasi. I numeri tra parentesi () nella figura
corrispondono agli elementi numerati nella descrizione successiva.
Controllo del commit
41
Viene qui di seguito riportata una descrizione degli eventi per l'elaborazione normale senza
l'ottimizzazione di ultimo agent quando l'agent dà l'indicazione di OK tralasciare. È rappresentata la
descrizione di un flusso di base. La sequenza di eventi può diventare molto più complessa quando la rete
del programma di transazione ha più livelli o quando si verificano degli errori.
1. Il programma applicativo A esegue un'operazione di ricezione richiesta per indicare che è pronto a
ricevere una richiesta dal programma I.
2. L'applicazione iniziatore (I) emette un'istruzione di commit.
3. Il gestore transazioni per l'iniziatore (TM-I) assume il ruolo di iniziatore per questa transazione.
Avvia la fase di preparazione inviando un messaggio di preparazione a tutte le altre ubicazioni che
stanno partecipando alla transazione.
4. I gestori transazioni per tutte le altre ubicazioni assumono il ruolo di agent (TM-A). Il programma
applicativo A viene informato da TM-A che è stata ricevuta una richiesta di commit. Per i file ICF, la
notifica consiste nell'impostazione dell'indicatore ICF di ricezione di un'esecuzione di commit
(RCVTKCMT).
5. Il programma applicativo A risponde immettendo un'istruzione di commit (o un'istruzione di
rollback). Questa è la decisione del programma applicativo.
6. Se il programma applicativo A ha utilizzato l'API QTNCHGCO (Modifica opzioni di commit) per
impostare l'opzione di commit OK tralasciare su Y, viene inviato un indicatore quando l'agent
(TM-A) risponde all'iniziatore (TM-I) con un messaggio di richiesta di commit.
42
IBM i: Database Controllo del commit
Nota: qualsiasi modifica all'opzione di commit OK tralasciare non diventa effettiva fino alla
successiva operazione di commit eseguita correttamente.
7. Quando l'iniziatore (TM-I) riceve tutte le decisioni, il TM-I invia un messaggio di commit. Questo
avvia la fase di commit.
8. Ciascun agent (TM-A) esegue il commit e risponde con un messaggio di reimpostazione.
9. Una restituzione viene inviata al programma applicativo (I) per indicare che la transazione è
completa presso l'iniziatore.
10. Su TM-I può verificarsi qualsiasi numero di transazioni, nessuna delle quali richiede delle modifiche
a TM-A o dati da TM-A. TM-A non è incluso in queste transazioni.
11. La volta successiva che l'iniziatore (TM-I) invia un messaggio all'agent (A), un nuovo ID transazione
viene inviato con il messaggio. Se l'iniziatore esegue qualche operazione di commit o di rollback
prima di inviare un messaggio all'agent, nessun messaggio viene inviato all'agent durante queste
operazioni (l'agent viene "escluso" da questi commit o rollback). Poiché una o più transazioni
potrebbero essere state sottoposte a commit o rollback presso l'iniziatore mentre l'agent era escluso,
l'iniziatore deve comunicare il suo ID transazione corrente quando viene inviato il messaggio
successivo all'agent.
12. Una restituzione viene inviata al programma applicativo (A) per indicare che il commit originario è
completo e che sta partecipando alla transazione corrente.
Concetti correlati
“Ottimizzazione delle prestazioni per il controllo del commit” a pagina 71
L'utilizzo del controllo del commit richiede delle risorse che possono influenzare le prestazioni del
sistema. Diversi fattori influenzano le prestazioni del sistema relativamente al controllo del commit.
Definizione di commit per un commit in due fasi: non selezione di un ultimo agent:
Per impostazione predefinita, il gestore transazioni per l'iniziatore può selezionare qualsiasi agent come
un ultimo agent durante un'operazione di commit.
Nota: l'opzione che indica di non selezionare l'ultimo agent non è valida se si sta utilizzando l'unità di
lavoro distribuita DRDA su una connessione TCP/IP.
Nel caso di un albero a più livelli, qualsiasi agent selezionato come ultimo agent dal suo iniziatore può
anche selezionare un proprio ultimo agent. Le prestazioni sono migliorate quando un ultimo agent viene
selezionato durante l'operazione di commit perché i due flussi di comunicazioni vengono eliminati tra un
iniziatore e il suo ultimo agent (la fase di preparazione viene eliminata per questi sistemi).
Tuttavia, quando invia la richiesta di commit al suo ultimo agent, l'iniziatore deve attendere finché non
avrà ricevuto la decisione dell'ultimo agent prima di poter continuare. Questo è indipendente dal valore
di Attesa risultato per la definizione di commit. Durante la normale elaborazione di commit senza errori,
questo non è un problema. Se però si verifica un errore durante questo intervallo di tempo, l'iniziatore
non può continuare finché non sarà stata completata la risincronizzazione. Se l'applicazione iniziatore sta
gestendo richieste da un utente a un terminale, questa può essere una considerazione di utilizzabilità.
È necessario considerare se delle prestazioni migliorate durante le normali operazioni di commit sono più
importanti dell'impatto sull'utilizzabilità quando si verifica un errore di questo tipo. Nota: se l'errore si
verifica prima che la richiesta di commit venga inviata all'ultimo agent, la LUW (Logical Unit of Work unità di lavoro logica) eseguirà immediatamente il rollback e l'iniziatore non attenderà. Pertanto,
l'intervallo di tempo durante il quale un errore può causare una condizione di attesa per l'iniziatore è
abbastanza piccolo e, pertanto, un errore di questo tipo è raro.
Se si decide che l'impatto sull'utilizzabilità è eccessivo rispetto al miglioramento delle prestazioni
ottenuto, è possibile modificare le definizioni di commit per non selezionare un ultimo agent. Dopo aver
avviato il controllo del commit, è possibile utilizzare l'API QTNCHGCO (Modifica opzioni di commit) per
modificare l'opzione Ultimo agent consentito in N.
Controllo del commit
43
Riferimenti correlati
Change Commitment Options (QTNCHGCO) API
Effetto della decisione affidabile sul flusso di elaborazione di commit:
La decisione affidabile è un'ottimizzazione che migliora le prestazioni velocizzando la restituzione
all'applicazione iniziatore dopo un'operazione di commit ed eliminando un messaggio durante
un'operazione di commit.
Non esiste alcuna ottimizzazione di decisione affidabile esplicita per l'unità di lavoro distribuita DRDA
(Distributed Relational Database Architecture) su TCP/IP. Tuttavia, il sistema operativo i5/OS non
richiede mai una conferma di reimpostazione (ignora) per le connessioni TCP/IP. Pertanto, una
reimpostazione (ignora) è sempre implicita per le connessioni TCP/IP.
Dopo aver avviato il controllo del commit, è possibile utilizzare l'API QTNCHGCO (Modifica opzioni di
commit) per modificare l'opzione Accettazione decisione affidabile in Y.
Si può pensare alla decisione affidabile come a una promessa da parte di un agent al suo iniziatore che
non verranno prese decisioni euristiche presso l'agent se si verifica un errore nelle comunicazioni mentre
l'agent è in dubbio. Un agent che sta utilizzando l'ottimizzazione di decisione affidabile invia un
indicatore all'iniziatore durante la fase di preparazione del commit. Se anche l'iniziatore sta utilizzando
l'ottimizzazione di decisione affidabile, esso invia un indicatore all'agent che non è richiesta alcuna
reimpostazione in risposta al messaggio di commit. Questo elimina il messaggio di reimpostazione e
consente al gestore transazioni di eseguire la restituzione all'applicazione presso l'iniziatore appena viene
inviato il messaggio di commit.
Prendere in considerazione la possibilità di utilizzare l'ottimizzazione di decisione affidabile se ricorrono
le seguenti condizioni:
v È improbabile che venga presa una decisione euristica presso un agent in dubbio se si verifica un
errore di sistema o nelle comunicazioni a meno che l'errore non possa essere riparato.
v La logica di programma non richiede i risultati delle transazioni precedenti per assicurare che i file di
database rimangano sincronizzati.
L'ottimizzazione di decisione affidabile viene utilizzata dal sistema operativo i5/OS solo se ricorrono
tutte le seguenti condizioni:
v Le ubicazioni iniziatore e agent supportano il livello di presunta fine anomala del controllo del commit.
v L'ubicazione iniziatore accetta l'indicazione di decisione affidabile dall'agent. Sugli iniziatori i5/OS,
questo dipende dal valore delle due opzioni di commit:
– Il valore dell'opzione di commit Attesa risultato deve essere N (Sì è il valore predefinito).
– Il valore dell'opzione di commit Accettazione decisione affidabile deve essere Sì (Sì è il valore
predefinito).
v L'ubicazione dell'agent dà un'indicazione di decisione affidabile durante la fase di preparazione. Gli
agent i5/OS danno sempre un'indicazione di decisione affidabile. Questo è dovuto al fatto che le
decisioni euristiche possono essere prese solo tramite una procedura manuale che avverte dei possibili
effetti collaterali negativi che esse comportano.
Flusso di elaborazione di commit con l'ottimizzazione di decisione affidabile
La seguente figura mostra il flusso di messaggi tra i programmi applicativi e i gestori transazioni quando
viene utilizzata l'ottimizzazione di decisione affidabile. Sia il programma applicativo iniziatore sia i
programmi applicativi agent non rilevano l'elaborazione di commit in due fasi. I numeri tra parentesi ()
nella figura corrispondono agli elementi numerati nella descrizione successiva.
44
IBM i: Database Controllo del commit
Il seguente elenco descrive gli eventi per l'elaborazione normale senza l'ottimizzazione di ultimo agent
quando l'agent dà l'indicazione di decisione affidabile. È rappresentata la descrizione di un flusso di base.
La sequenza di eventi può diventare molto più complessa quando la rete del programma di transazione
ha più livelli o quando si verificano degli errori.
1. Il programma applicativo A esegue un'operazione di ricezione richiesta per indicare che è pronto a
ricevere una richiesta dal programma I.
2. L'applicazione iniziatore (I) emette un'istruzione di commit.
3. Il gestore transazioni per l'iniziatore (TM-I) assume il ruolo di iniziatore per questa transazione. Avvia
la fase di preparazione inviando un messaggio di preparazione a tutte le altre ubicazioni che stanno
partecipando alla transazione.
4. I gestori transazioni per tutte le altre ubicazioni assumono il ruolo di agent (TM-A). Il programma
applicativo A viene informato da TM-A che è stata ricevuta una richiesta di commit. Per i file ICF, la
notifica consiste nell'impostazione dell'indicatore ICF di ricezione di un'esecuzione di commit
(RCVTKCMT).
5. Il programma applicativo A risponde immettendo un'istruzione di commit (o un'istruzione di
rollback). Questa è la decisione del programma applicativo.
6. L'agent (TM-A) risponde all'iniziatore (TM-I) con un messaggio di richiesta di commit. I sistemi i5/OS
un indicatore affidabile di voto con la richiesta di commit.
7. Quando l'iniziatore (TM-I) riceve tutte le decisioni, il TM-I invia un messaggio di commit. Se l'opzione
di commit Attesa risultato è N (No) e l'opzione di commit Accettazione decisione affidabile è Y (Sì),
con il messaggio di commit viene inviato un indicatore di non reimpostazione. Questo indica all'agent
che non è richiesto alcun messaggio di reimpostazione in risposta al commit.
Controllo del commit
45
8. La transazione è completa. Una restituzione viene inviata ai programmi applicativi (I e A). Questa
restituzione indica che l'operazione di commit è stata eseguita correttamente. Se si verifica un danno
euristico sul sistema A dovuto a una decisione euristica presa prima che fosse ricevuto il messaggio di
commit eseguito, l'applicazione I non viene informata. Viene invece inviato un messaggio alla coda
messaggi QSYSOPR. Tuttavia, l'applicazione A riceve l'indicazione di danno euristico.
9. La vota successiva che l'agent (TM-A) invia un messaggio all'iniziatore (TM-I), sia esso un flusso di
dati o un'istruzione di commit, un indicatore di reimpostazione implicita viene inviato insieme al
messaggio per informare TM-I che TM-A ha completato il commit correttamente. Questo è dovuto al
fatto che TM-I deve conservare le informazioni sulla transazione completata finché non conferma che
TM-A ha ricevuto correttamente il messaggio di commit nel passo 7 a pagina 45
Riferimenti correlati
Change Commitment Options (QTNCHGCO) API
Supporto delle transazioni XA per il controllo del commit
DB2 for i può partecipare nelle transazioni globali X/Open.
The Open Group ha definito un modello standard del settore per il lavoro transazionale che consente a
modifiche apportate a risorse non correlate di far parte di una singola transazione globale. Un esempio è
rappresentato da modifiche ai database forniti da due fornitori separati. Questo modello è detto modello
X/Open Distributed Transaction Processing.
Le seguenti pubblicazioni descrivono in modo dettagliato il modello X/Open Distributed Transaction
Processing:
v X/Open Guide, February 1996, Distributed Transaction Processing: Reference Model, Version 3
(ISBN:1-85912-170-5, G504), The Open Group.
v X/Open CAE Specification, December 1991, Distributed Transaction Processing: The XA Specification
(ISBN:1-872630-24-3, C193 o XO/CAE/91/300), The Open Group.
v X/Open CAE Specification, April 1995, Distributed Transaction Processing: The TX (Transaction
Demarcation) Specification (ISBN:1-85912-094-6, C504), The Open Group.
È necessario avere dimestichezza con le informazioni contenute in questi manuali, in particolar modo con
la specifica XA, prima di provare a utilizzare il supporto delle transazioni XA fornito da DB2 for i. Questi
manuali sono disponibili sul sito Web della The Open Group.
Il modello DTP (distributed transaction processing) presenta cinque componenti:
AP (application program, ossia programma applicativo)
Implementa la funzione richiesta dell'utente specificando una sequenza di operazioni che
coinvolge risorse come ad esempio i database. Definisce l'inizio e la fine delle transazioni globali,
accede alle risorse nei limiti delle transazioni e, di norma, decide se eseguire il commit o il
rollback di ciascuna transazione.
TM (transaction manager, ossia gestore transazioni)
Gestisce le transazioni globali e coordina la decisione di avviarle e di eseguirne il commit, o di
eseguirne il rollback per assicurare il completamento della transazione atomica (indivisibile). Il
TM coordina anche le attività di ripristino con gli RM dopo il malfunzionamento di un
componente.
RM (resource manager, ossia gestore risorse)
Gestisce una parte definita delle risorse condivise del computer, come ad esempio un sistema di
gestione del database. L'AP utilizza interfacce definite da ogni RM per eseguire il lavoro
transazionale. Il TM utilizza le interfacce fornite dall'RM per eseguire il completamento della
transazione.
46
IBM i: Database Controllo del commit
CRM (communications resource manager)
Consente a un'istanza del modello di accedere a un'altra istanza interna o esterna al dominio TM
corrente. I CRM non rientrano nell'ambito di DB2 for i e non sono trattati in questa
pubblicazione.
Protocollo per le comunicazioni
I protocolli sono utilizzati dai CRM per comunicare tra loro. Questo non rientra nell'ambito di
DB2 for i e non è trattato in questa pubblicazione.
La specifica XA è la parte del modello DTP che descrive un set di interfacce utilizzato dai componenti
TM ed RM del modello DTP. DB2 for i implementa queste interfacce come un set di programmi di uscita
e di API in stile piattaforma UNIX®. Consultare API XA per una documentazione dettagliata di queste
API e per ulteriori informazioni su come utilizzare DB2 for i come un RM.
System i Navigator e le transazioni XA
System i Navigator supporta la gestione di transazioni XA come transazioni globali.
Una transazione globale può contenere modifiche sia esterne sia interne a DB2 for i. Una transazione
globale è coordinata da un gestore transazioni esterno che utilizza l'architettura Open Group XA o
un'altra architettura simile. Un'applicazione esegue il commit o il rollback di una transazione globale
utilizzando le interfacce fornite dal gestore transazioni. Il gestore transazioni utilizza protocolli di commit
definiti dall'architettura XA, o da un'altra architettura, per completare la transazione. DB2 for i funge da
gestore risorse XA quando partecipa a una transazione globale. Esistono due tipi di transazioni globali:
v Blocchi nell'ambito della transazione: i blocchi acquisiti per conto della transazione sono inclusi
nell'ambito della transazione. La transazione può spostarsi da un lavoro o un sottoprocesso ad un altro.
v Blocchi nell'ambito del lavoro: i blocchi acquisiti per conto della transazione sono inclusi nell'ambito
del lavoro. La transazione non può spostarsi dal lavoro che l'ha avviata.
Considerazioni per le transazioni XA
Le API XA per i blocchi nell'ambito della transazione sono consigliate per i nuovi utenti del supporto
delle transazioni XA. Le API XA per i blocchi nell'ambito del lavoro continueranno a essere supportate
ma non presenteranno più alcun vantaggio rispetto alle API XA per i blocchi nell'ambito della
transazione. Le API XA per i blocchi nell'ambito della transazione presentano meno limitazioni e offrono
migliori prestazioni nelle seguenti situazioni:
v Se vengono utilizzate più connessioni SQL per gestire un singolo ramo transazione XA.
v Se viene utilizzata una singola connessione SQL per gestire più rami transazione XA simultanei.
In queste situazioni, è necessario avviare un lavoro separato per eseguire i rami transazione XA quando si
utilizzano le API XA per i blocchi nell'ambito del lavoro.
Leggere attentamente le seguenti considerazioni e comprendere le seguenti limitazioni prima di utilizzare
DB2 for i come un RM. Il termine sottoprocesso fa riferimento a un lavoro che non ha capacità di
sottoprocesso oppure a un singolo sottoprocesso in un lavoro con capacità di sottoprocesso.
Le seguenti considerazioni sono valide sia per le transazioni con i blocchi nell'ambito della transazione
sia per le transazioni con i blocchi nell'ambito del lavoro, se non diversamente indicato.
Considerazioni su DB2 for i
v Le transazioni XA su un database locale devono essere eseguite in lavori in esecuzione in modalità
server SQL. Per questo tipo di transazioni, se viene utilizzata l'API xa_open() o db2xa_open() in un
lavoro che non è già in esecuzione in modalità server SQL, la modalità server SQL viene avviata in
modo implicito. È possibile fare riferimento a API XA per le limitazioni sulle interfacce di database
supportate.
Controllo del commit
47
v
le transazioni XA su un database remoto devono utilizzare la modalità server SQL quando si
utilizzano le API XA per i blocchi nell'ambito del lavoro. Tuttavia, la modalità server è facoltativa per
le transazioni XA su un database remoto quando si utilizzano le API XA per i blocchi nell'ambito della
transazione. Inoltre, le modifiche ai file DDM utilizzando i classici metodi di accesso al database i5/OS
sono consentite nelle transazioni XA su un database remoto quando non viene utilizzata la modalità
server SQL.
v Durante i richiami di API XA, la specifica XA notifica eventuali errori rilevati da DB2 for i tramite i
codici di ritorno. I messaggi di diagnostica vengono lasciati nella registrazione lavoro quando non è
possibile determinare il significato dell'errore dal solo codice di ritorno.
Considerazioni sull'SQL incorporato
v Per utilizzare una connessione SQL (Structured Query Language) per le transazioni XA, è necessario
utilizzare l'API (application programming interface) xa_open() o db2xa_open() prima che venga
stabilita la connessione SQL. Il database relazionale con il quale verrà stabilita la connessione deve
essere trasmesso all'API xa_open() o db2xa_open() dal parametro xainfo. Il profilo utente e la parola
d'ordine da utilizzare nel lavoro cui viene instradata la connessione potrebbero essere trasmessi all'API
xa_open() o db2xa_open(). Se non viene trasmesso, il profilo utilizzato è quello che è stato specificato o
utilizzato come predefinito durante il tentativo di connessione.
Nota: la seguente considerazione è valida solo per le transazioni con blocchi nell'ambito del lavoro.
v Se per eseguire le transazioni XA viene utilizzato l'SQL incorporato, il lavoro eseguito per ciascuna
connessione viene instradato a un lavoro differente, anche se le connessioni vengono stabilite nello
stesso sottoprocesso. Questo è diverso dalla modalità server SQL senza XA, dove il lavoro eseguito per
tutte le connessioni in un singolo sottoprocesso viene instradato allo stesso lavoro. Questo è dovuto al
fatto che la specifica XA richiede una chiamata di preparazione, commit o rollback separata per
ciascuna istanza del gestore risorse.
Nota: la seguente considerazione è valida solo per le transazioni con blocchi nell'ambito del lavoro.
v Se per eseguire le transazioni XA viene utilizzato l'SQL incorporato, è possibile stabilire una sola
connessione per database relazionale per sottoprocesso. Quando il sottoprocesso non è attivamente
associato a un ramo transazione, il lavoro richiesto su una delle connessioni del sottoprocesso farà sì
che l'RM utilizzi il programma di uscita del TM ax_reg() per determinare se il lavoro consiste
nell'avviare, riprendere o eseguire l'unione a un ramo transazione.
Se il lavoro consiste nell'avviare un ramo transazione, esso viene eseguito sulla connessione di tale
sottoprocesso al database relazionale corrispondente.
Se il lavoro consiste nell'unirsi a un ramo transazione, esso viene reinstradato sulla connessione al
database relazionale corrispondente di cui era stata eseguita la creazione nel sottoprocesso che ha
avviato il ramo transazione. Notare che il sistema non impone che il profilo utente per la connessione
sia uguale a quello per la connessione del sottoprocesso di unione. È responsabilità del TM assicurarsi
che questo non rappresenti un problema per la sicurezza. I tipici TM utilizzano lo stesso profilo utente
per tutte le connessioni. Questo profilo utente è autorizzato a tutti i dati gestiti dal TM. Ulteriori
misure di sicurezza relative all'accesso a questi dati sono gestite dal TM o dall'AP invece di utilizzare
le tecniche di sicurezza IBM i standard.
Nota: la seguente considerazione è valida solo per le transazioni con blocchi nell'ambito del lavoro.
v Se il lavoro consiste nel riprendere un ramo transazione, la connessione utilizzata dipende dal fatto che
l'associazione di ramo transazione sospesa sia stata stabilita avviando un ramo transazione o unendosi
a esso.
Il successivo lavoro viene eseguito sulla stessa connessione finché non viene utilizzata l'API
db2xa_end() per sospendere o terminare l'associazione del sottoprocesso a tale ramo transazione.
Considerazioni sulla CLI
v Se per eseguire le transazioni XA viene utilizzata la CLI, potrebbe essere stabilita più di una
connessione nello stesso sottoprocesso dopo l'utilizzo dell'API db2xa_open(). Le connessioni possono
48
IBM i: Database Controllo del commit
essere utilizzate in altri sottoprocessi per eseguire delle transazioni XA, a condizione che questi altri
sottoprocessi utilizzino prima l'API db2xa_open() con lo stesso valore di parametro xainfo.
Nota: la seguente considerazione è valida solo per le transazioni con blocchi nell'ambito del lavoro.
v Se per eseguire le transazioni XA viene utilizzata la CLI, la connessione utilizzata per avviare un ramo
transazione deve essere utilizzata per tutto il lavoro su tale ramo transazione. Se un altro sottoprocesso
consiste nell'unirsi al ramo transazione, il gestore di connessione per la connessione utilizzata per
avviare il ramo transazione deve essere trasmesso al sottoprocesso di unione in modo che possa
eseguire il lavoro sulla stessa connessione. In modo analogo, se un sottoprocesso consiste nel
riprendere il ramo transazione, deve essere utilizzata la stessa connessione.
Poiché i gestori di connessione CLI non possono essere utilizzati in un lavoro differente, la funzione di
unione è limitata ai sottoprocessi in esecuzione nello stesso lavoro che ha avviato il ramo transazione
quando viene utilizzata la CLI.
Considerazioni sul database relazionale remoto
Nota: queste considerazioni relative a un database relazionale remoto sono valide solo per le transazioni
con dei blocchi nell'ambito del lavoro.
v Le connessioni XA a un database relazionale remoto sono supportate solo se il database relazionale si
trova su un sistema che supporta le connessioni DUW (Distributed Unit of Work - unità di lavoro
distribuita) DRDA. Questo include i prodotti System i che eseguono DRDA (Distributed Relational
Database Architecture) su conversazioni SNA LU 6.2 o che utilizzano V5R1 o successive quando
eseguono DRDA utilizzando connessioni TCP/IP. Questo include anche altre piattaforme che
supportano DRDA su SNA LU 6.2 o che supportano il protocollo XA utilizzando DRDA su TCP/IP.
v Prima di utilizzare la funzione di unione XA, l'API db2xa_open() deve essere utilizzata nel
sottoprocesso di unione. È necessario specificare lo stesso nome di database relazionale e lo stesso
RMID nell'API db2xa_open() sia nel sottoprocesso che ha avviato il ramo transazione sia nel
sottoprocesso di unione. Se il ramo transazione è attivo quando viene tentata un'unione, il
sottoprocesso di unione viene bloccato. Il sottoprocesso di unione rimane bloccato finché il ramo attivo
non sospende o termina la sua associazione al ramo transazione.
Considerazioni sul ripristino
|
|
|
|
|
|
|
|
|
|
|
|
|
v Il supporto di rollback o commit euristico manuale fornito per tutte le definizioni di commit può essere
utilizzato se diventa necessario forzare un ramo transazione a eseguire il commit o il rollback mentre è
in uno stato di preparato.
v Il supporto di rollback euristico manuale è consentito anche per i rami transazione che sono in uno
stato di attivo o inattivo. Questo supporto è soprattutto importante quando si verifica un errore di
connessione client dopo che l'API xa_end è stata utilizzata per passare il ramo transazione allo stato di
inattivo ma prima dell'utilizzo di xa_commit o xa_rollback per completare la transazione. Se il gestore
transazioni del client non torna a completare il ramo transazione inattivo dopo l'errore di connessione,
il ramo transazione inattivo diventa orfano e rimarrà in sospeso finché il sistema non viene riavviato o
finché non viene eseguito un rollback euristico manuale.
v Esiste anche un'opzione manuale per ignorare i rami transazione che sono in uno stato di completato
euristicamente. Se un gestore transazioni non si attiene al protocollo XA per emettere l'API xa_forget
dopo aver ricevuto un codice di ritorno di decisione euristica, il ramo transazione diventa orfano e
rimarrà nello stato di euristicamente completato anche se viene eseguito un riavvio del sistema. Il ramo
transazione non detiene modifiche in sospeso o blocchi in questo stato ma consuma memoria di
sistema che viene liberata quando viene applicata l'opzione "ignora".
Considerazioni sui rami transazione
v Le informazioni sui rami transazione XA vengono visualizzate come parte delle informazioni sul
controllo del commit visualizzate da System i Navigator e dai comandi WRKJOB (Gestione lavoro),
DSPJOB (Visualizzazione lavoro) e WRKCMTDFN (Gestione definizioni di commit). Il nome TM, lo
stato del ramo transazione, l'identificativo della transazione e il qualificatore ramo vengono tutti
Controllo del commit
49
visualizzati. Le definizioni di commit correlate alle transazioni XA attualmente attive possono essere
visualizzate utilizzando il comando WRKCMTDFN JOB(*ALL) STATUS(*XOPEN) o visualizzando la cartella
Transazioni globali in System i Navigator.
Nota: la seguente voce è valida solo per le transazioni con blocchi nell'ambito del lavoro.
v Se un'associazione tra un sottoprocesso e un ramo transazione esistente viene sospesa o terminata
utilizzando l'API db2xa_end(), il sottoprocesso potrebbe avviare un nuovo ramo transazione. Se la
connessione utilizzata per avviare il nuovo ramo transazione è stata utilizzata precedentemente per
avviare un ramo transazione differente e l'associazione del sottoprocesso con tale ramo transazione è
stata terminata o sospesa dall'API db2xa_end(), potrebbe essere avviato un nuovo lavoro server SQL.
Un nuovo lavoro server SQL occorre solo se il primo ramo transazione non è stato ancora completato
dall'API db2xa_commit() o db2xa_rollback(). In questo caso, alla registrazione lavoro viene inviato un
altro messaggio di completamento SQL7908 che identifica il nuovo lavoro server SQL, proprio come il
lavoro server SQL originario della connessione era stato identificato quando era stata stabilita la
connessione. Tutte le richieste SQL per il nuovo ramo transazione vengono instradate al nuovo lavoro
server SQL. Quando il ramo transazione viene completato dall'API db2xa_commit() o db2xa_rollback(),
il nuovo lavoro server SQL viene riciclato (arrestato e riavviato) e restituito al lotto del lavoro di
preavvio.
v Un ramo transazione viene contrassegnato come Solo rollback nelle seguenti situazioni solo per le
transazioni XA per i blocchi nell'ambito del lavoro:
– Un sottoprocesso termina mentre è ancora associato al ramo transazione. Questo include un
sottoprocesso che termina in seguito alla terminazione di un processo.
– Si verifica un malfunzionamento del sistema.
v Con le transazioni XA per i blocchi nell'ambito della transazione, un ramo transazione viene sottoposto
a rollback dal sistema se qualche sottoprocesso è ancora associato a esso quando si verifica una delle
seguenti situazioni:
– La connessione correlata al ramo transazione viene terminata.
– Il lavoro che ha avviato il ramo transazione viene terminato.
– Si verifica un malfunzionamento del sistema.
Nota: la seguente considerazione è valida solo per le transazioni con blocchi nell'ambito del lavoro.
v Esiste una situazione in cui un ramo transazione verrà sottoposto a rollback dal sistema,
indipendentemente dal fatto che ci siano ancora dei sottoprocessi associati. Questo si verifica quando il
lavoro server SQL cui si sta instradando il lavoro della connessione viene terminato. Questo si verifica
solo quando su tale lavoro viene utilizzato il comando CL ENDJOB (Fine lavoro).
v Un ramo transazione non è interessato da questa condizione se nessun sottoprocesso ha
un'associazione attiva ad esso quando si verifica una delle seguenti situazioni. Il TM può eseguire il
commit o il rollback del ramo transazione da qualsiasi sottoprocesso che ha utilizzato l'API xa_open() o
db2xa_open() con lo stesso valore di parametro xainfo che era stato specificato nel sottoprocesso che ha
avviato il ramo transazione.
– La connessione correlata al ramo transazione viene terminata.
– Un sottoprocesso o un lavoro che ha eseguito del lavoro per il ramo transazione utilizza l'API
xa_close() o db2xa_close().
– Si verifica un malfunzionamento del sistema. In questo caso, il ramo transazione non è interessato
da questa condizione solo se è in uno stato di preparato. Se si trova nello stato di inattivo, il sistema
ne esegue il rollback.
v Quando gli identificativi transazione (XID) di due rami transazione XA hanno lo stesso identificativo
transazione globale (GTRID), ma qualificatori ramo (BQUAL) differenti, vengono indicati come
liberamente accoppiati (o loosely coupled). Per impostazione predefinita, i rami transazione liberamente
accoppiati non condividono blocchi. Tuttavia, quando si utilizzano le API XA per i blocchi nell'ambito
della transazione, esiste un'opzione che consente alle transazioni liberamente accoppiate di condividere
blocchi.
50
IBM i: Database Controllo del commit
Concetti correlati
“Considerazioni per le transazioni XA” a pagina 25
Nell'ambiente XA, ciascun database viene considerato un gestore risorsa separato. Quando un gestore
transazioni desidera accedere a due database sotto la stessa transazione, deve utilizzare i protocolli XA
per eseguire un commit in due fasi con i due gestori risorse.
The Open Group Web site
“Modalità server SQL e transazioni nell'ambito del sottoprocesso per il controllo del commit”
Le definizioni di commit con dei blocchi nell'ambito del lavoro sono di solito inclusi nell'ambito di un
gruppo di attivazione.
Attività correlate
“Quando forzare le opzioni di commit e di rollback e quando annullare la risincronizzazione” a pagina
117
La decisione di forzare un'operazione di commit o di rollback viene detta decisione euristica. Questa azione
abilita un operatore ad eseguire il commit o il rollback manualmente delle risorse per una transazione che
è in uno stato Preparato.
Modalità server SQL e transazioni nell'ambito del sottoprocesso per il
controllo del commit
Le definizioni di commit con dei blocchi nell'ambito del lavoro sono di solito inclusi nell'ambito di un
gruppo di attivazione.
Se un lavoro è a più sottoprocessi, tutti i sottoprocessi nel lavoro hanno accesso alla definizione di
commit e le modifiche apportate per una specifica transazione possono essere distribuite su più
sottoprocessi. In altri termini, tutti i sottoprocessi i cui programmi vengono eseguiti nello stesso gruppo
di attivazione partecipano a una singola transazione.
Ci sono casi in cui è desiderabile che il lavoro transazionale sia incluso nell'ambito del sottoprocesso
piuttosto che di un gruppo di attivazione. In altre parole, ogni sottoprocesso ha una propria definizione
di commit e un proprio lavoro transazionale poiché ciascuna definizione di commit è indipendente dal
lavoro eseguito in altri sottoprocessi.
DB2 for i fornisce questo supporto utilizzando l'API QWTCHGJB (Modifica lavoro) per modificare il
lavoro da eseguire in modalità server SQL. Quando è richiesta in modalità server SQL, una connessione
SQL viene instradata a un lavoro separato. Anche tutte le successive operazioni SQL eseguite per tale
connessione vengono instradate a tale lavoro. Quando viene stabilita la connessione, il messaggio di
completamento SQL7908 viene inviato alla registrazione lavoro del lavoro in modalità server SQL con
l'indicazione del lavoro cui si stanno instradando le richieste SQL. La definizione di commit appartiene al
lavoro indicato in questo messaggio. Se si verificano degli errori, potrebbe essere necessario consultare le
registrazioni lavoro per entrambi i lavori per comprendere l'origine del problema perché nessuna
operazione effettiva viene eseguita nel lavoro che esegue le istruzioni SQL.
In fase di esecuzione in modalità server SQL, solo le interfacce SQL possono essere utilizzate per eseguire
delle operazioni sotto il controllo del commit. È possibile utilizzare l'SQL incorporato o CLI (Call Level
Interface). Tutte le connessioni stabilite tramite l'SQL incorporato in un singolo sottoprocesso sono
instradate allo stesso lavoro di back-end. Questo consente a una singola richiesta di commit di eseguire il
commit del lavoro per tutte le connessioni, proprio come può essere in un lavoro che non è in esecuzione
in modalità server SQL. Ciascuna connessione stabilita tramite la CLI viene instradata a un lavoro
separato. La CLI richiede che il lavoro eseguito per ciascuna connessione venga sottoposto a commit o a
rollback indipendentemente.
Non è possibile effettuare le seguenti operazioni sotto il controllo del commit quando si è in esecuzione
in modalità server SQL:
v Modifiche di record eseguite con delle interfacce che non siano interfacce SQL
Controllo del commit
51
v Modifiche ai file DDM
v Modifiche alle risorse di commit API
Non è possibile avviare il controllo del commit direttamente in un lavoro in esecuzione in modalità
server SQL.
Concetti correlati
“Supporto delle transazioni XA per il controllo del commit” a pagina 46
DB2 for i può partecipare nelle transazioni globali X/Open.
Running DB2 CLI in server mode
Starting DB2 CLI in SQL server mode
Restrictions for running DB2 CLI in server mode
Riferimenti correlati
Change Job (QWTCHGJB) API
Avvio del controllo del commit
Per avviare il controllo del commit, utilizzare il comando STRCMTCTL (Avvio controllo commit).
Nota: il controllo del commit non deve necessariamente essere avviato dalle applicazioni SQL. SQL avvia
in modo implicito il controllo del commit in fase di connessione quando il livello di isolamento
SQL è diverso da *NONE.
Quando si utilizza il comando STRCMTCTL, è possibile specificare questi parametri.
Livello di blocco del commit
Specificare il livello di blocco con il parametro LCKLVL nel comando STRCMTCTL. Il livello
specificato diventa il livello predefinito di blocco di record per i file di database aperti e posti
sotto il controllo del commit per la definizione di commit.
Oggetto di notifica del commit
Utilizzare il parametro NTFY per specificare l'oggetto di notifica. Un oggetto di notifica è una
coda messaggi, un'area dati o un file di database che contiene le informazioni che identificano
l'ultima transazione eseguita correttamente completata per una specifica definizione di commit se
tale definizione di commit non è stata terminata normalmente.
Parametro di ambito del commit
Utilizzare il parametro CMTSCOPE per specificare l'ambito del commit. Quando viene avviato il
controllo del commit, il sistema crea una definizione di commit. Il parametro di ambito del
commit identifica l'ambito per la definizione di commit. Il valore predefinito consiste
nell'includere la definizione di commit nell'ambito del gruppo di attivazione del programma che
esegue la richiesta di avvio del controllo del commit. L'ambito alternativo è quello del lavoro.
Parametro di giornale predefinito
È possibile specificare un giornale predefinito quando si avvia il controllo del commit. È possibile
utilizzare un giornale predefinito per questi motivi:
v Si desidera catturare le voci di giornale della transazione. Queste voci possono essere di ausilio
nell'analisi della cronologia di quali risorse sono associate a una transazione. Non sono
utilizzate per applicare e rimuovere modifiche registrate su giornale. Il parametro delle voci
giornale da omettere (OMTJRNE) determina se il sistema scrive le voci di transazione.
v Si desidera migliorare le prestazioni per i lavori che chiudono file e li aprono nuovamente in
un passo di instradamento. Se si chiudono tutti i file assegnati a un giornale che non è quello
predefinito, tutte le informazioni di sistema sul giornale vengono eliminate dal passo di
instradamento. Se un file assegnato a tale giornale viene aperto successivamente, tutte le
52
IBM i: Database Controllo del commit
informazioni sul giornale devono essere create nuovamente. Il sistema conserva le informazioni
sul giornale predefinito con la definizione di commit, se qualche risorsa assegnata al giornale è
attiva.
Parametro di testo del commit
Utilizzare il parametro TEXT per identificare il testo specifico da associare a una definizione di
commit quando si visualizzano le informazioni sulle definizioni di commit avviate per un lavoro.
Se non viene specificato del testo, il sistema fornisce una descrizione di testo predefinita.
Parametro di omissione di voci del giornale
Se si specifica un giornale predefinito per migliorare le prestazioni, è possibile utilizzare il
parametro OMTJRNE per impedire al sistema di scrivere delle voci di giornale della transazione.
Quando il sistema scrive delle voci di transazione, la dimensione del ricevitore di giornale
aumenta notevolmente, con una conseguente riduzione delle prestazioni durante le operazioni di
commit e rollback.
Le voci di transazione possono essere utili durante la configurazione e la verifica dell'ambiente di
controllo del commit o di una nuova applicazione.
Le voci di transazione vengono scritte nel giornale predefinito indipendentemente dal valore del
parametro OMTJRNE quando si verificano le seguenti condizioni:
v Si verifica un errore di sistema durante un'operazione di commit o rollback.
v Viene apportata una modifica manuale a una risorsa che partecipava a una transazione e la
modifica ha causato una condizione euristica mista. Consultare la sezione Stati della
transazione per il controllo del commit in due fasi per una descrizione della condizione
euristica mista. Questo tipo di modifica manuale è detto decisione euristica.
È possibile utilizzare le informazioni che indicano quali risorse partecipavano alla transazione per
determinare quale azione eseguire in queste situazioni.
È possibile utilizzare il programma di ricerca delle informazioni sulle voci del giornale per
visualizzare i layout dei dati specifici per le voci di giornale della transazione (controllo del
commit).
Concetti correlati
“Stati della transazione per il controllo del commit a due fasi” a pagina 31
Una definizione di commit viene stabilita su ciascuna ubicazione che fa parte della rete del programma di
transazione. Per ciascuna definizione di commit, il sistema tiene traccia dello stato della sua transazione
corrente e della transazione precedente.
Journal entry information finder
Attività correlate
“Quando forzare le opzioni di commit e di rollback e quando annullare la risincronizzazione” a pagina
117
La decisione di forzare un'operazione di commit o di rollback viene detta decisione euristica. Questa azione
abilita un operatore ad eseguire il commit o il rollback manualmente delle risorse per una transazione che
è in uno stato Preparato.
Riferimenti correlati
Start Commitment Control (STRCMTCTL) command
Oggetto di notifica del commit
Un oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioni
che identificano l'ultima transazione eseguita correttamente completata per una specifica definizione di
commit se tale definizione di commit non è stata terminata normalmente.
Le informazioni utilizzate per identificare l'ultima transazione eseguita correttamente per una definizione
di commit vengono fornite dall'identificazione di commit che associa un'operazione di commit a una
specifica serie di modifiche di risorse di cui è possibile eseguire il commit.
Controllo del commit
53
L'identificazione di commit dell'ultima transazione eseguita correttamente per una definizione di commit
viene inserita nell'oggetto di notifica solo se la definizione di commit non termina normalmente. Le
informazioni possono essere utilizzate per aiutare a determinare dove è terminata l'elaborazione di
un'applicazione, in modo che l'applicazione può essere avviata nuovamente.
Per i lotti dischi indipendenti, l'oggetto di notifica deve trovarsi sullo stesso lotto dischi indipendente o
gruppo di lotti dischi indipendenti della definizione di commit. Se si sposta la definizione di commit in
un altro lotto dischi indipendente o gruppo di lotti dischi indipendenti, anche l'oggetto di notifica deve
trovarsi sull'altro lotto dischi indipendente o gruppo di lotti dischi indipendenti. L'oggetto di notifica
sull'altro lotto dischi indipendente o gruppo di lotti dischi indipendenti viene aggiornato se si verifica
una fine anomala della definizione di commit. Se l'oggetto di notifica non viene trovato sull'altro lotto
dischi indipendente o gruppo di lotti dischi indipendenti, l'aggiornamento ha esito negativo con il
messaggio CPF8358.
Se le risorse registrate su giornale partecipano alla transazione corrente e viene eseguita un'operazione di
commit con un'identificazione di commit, l'identificazione di commit viene inserita nella voce di giornale
di commit (codice giornale e tipo di voce C CM) che identifica quella specifica transazione come in fase
di commit. Una voce di giornale di commit che contiene l'identificazione di commit viene inviata a
ciascun giornale associato alle risorse che partecipavano alla transazione.
La seguente tabella mostra come specificare l'identificazione di commit e la sua dimensione massima. Se
supera la sua dimensione massima, l'identificazione di commit viene troncata quando viene scritta
nell'oggetto di notifica.
Linguaggio
Operazione
Numero massimo di caratteri
nell'identificazione di commit
CL
Comando COMMIT
3000
1
ILE (Integrated Language
Environment) RPG
Codice operazione COMIT
4000
1
PLI
Sottoroutine PLICOMMIT
4000
1
ILE C
Funzione _Rcommit
4000
1
ILE COBOL
Verbo COMMIT
Non supportato
SQL
Istruzione COMMIT
Non supportato
1
Nota: Se l'oggetto di notifica è un'area dati, la dimensione massima è 2000 caratteri.
Quando un oggetto di notifica viene aggiornato con l'identificazione di commit, viene aggiornato nel
seguente modo:
File di database
Se un file di database viene utilizzato come l'oggetto di notifica, l'identificazione di commit viene
aggiunta alla fine del file. Eventuali record esistenti verranno lasciati nel file. Poiché è possibile
che più utenti o lavori modifichino i record contemporaneamente, ciascuna identificazione di
commit nel file contiene delle informazioni univoche per associare i dati al lavoro e alla
definizione di commit per cui si è verificato l'esito negativo. Il file che funge da oggetto di
notifica può essere registrato su giornale
Area dati
Se un'area dati viene utilizzata come oggetto di notifica, l'intero contenuto dell'area dati viene
sostituito quando l'identificazione di commit viene inserita nell'area dati. Se più di un utente o un
lavoro sta utilizzando lo stesso programma, solo l'identificazione di commit dall'ultima
definizione di commit che non è terminata normalmente si troverà nell'area dati. Di conseguenza,
un singolo oggetto di notifica di area dati potrebbe non produrre le informazioni corrette per
riavviare i programmi applicativi. Per risolvere questo problema, utilizzare un'area dati separata
per ciascuna definizione di commit per ciascun lavoro o utente della stazione di lavoro.
54
IBM i: Database Controllo del commit
Coda messaggi
Se una coda messaggi viene utilizzata come oggetto di notifica, il messaggio CPI8399 viene
inviato alla coda messaggi. L'identificazione di commit viene inserita nel testo di secondo livello
per il messaggio CPI8399. Come succede con l'utilizzo di un file di database per l'oggetto di
notifica, il contenuto di ciascuna identificazione di commit identifica in modo univoco una
specifica definizione di commit per un lavoro in modo che un programma applicativo possa
essere riavviato.
Concetti correlati
“Controllo del commit per le applicazioni batch” a pagina 27
Le applicazioni batch possono richiedere o meno il controllo del commit. In alcuni casi, un'applicazione
batch può eseguire una singola funzione di lettura di un file di immissione e di aggiornamento di un file
master. Tuttavia, è possibile utilizzare il controllo del commit per questo tipo di applicazione se è
importante avviarla nuovamente dopo una fine anomala.
“Esempio: utilizzo di un oggetto di notifica per avviare un'applicazione” a pagina 94
Quando viene avviato dopo una fine anomala, un programma può cercare una voce nell'oggetto di
notifica. Se la voce esiste, il programma può riavviare una transazione. Dopo che la transazione è stata
avviata nuovamente, l'oggetto di notifica viene cancellato dal programma per evitare che avvii la stessa
transazione un'ennesima volta.
Livello di blocco del commit
Il valore specificato per il parametro LCKLVL nel comando STRCMTCTL (Avvio controllo commit)
diventa il livello predefinito di blocco di record per i file di database aperti e posti sotto il controllo del
commit per la definizione di commit.
Il livello predefinito di blocco di record non può essere sovrascritto quando si aprono i file di database
locali. Tuttavia, i file di database cui accede tramite SQL utilizzano il livello di isolamento SQL corrente
effettivo quando viene emessa la prima istruzione SQL su di essi.
Il livello di blocco deve essere specificato in base alle proprie esigenze, ai periodi di attesa consentiti e
alle procedure di rilascio utilizzate con maggiore frequenza.
Le seguenti descrizioni si applicano solo ai file aperti sotto il controllo del commit:
Livello di blocco *CHG
Utilizzare questo valore se si desidera proteggere i record modificati da modifiche apportate da
altri lavori in esecuzione contemporaneamente. Per i file aperti sotto il controllo del commit, il
blocco è mantenuto per la durata della transazione. Per i file non aperti sotto il controllo del
commit, il blocco sul record viene detenuto solo da quando il record viene letto a quando viene
completata l'operazione di aggiornamento.
Livello di blocco *CS
Utilizzare questo valore per proteggere sia i record modificati sia quelli richiamati da modifiche
apportate da altri lavori in esecuzione contemporaneamente. I record richiamati non modificati
sono protetti solo fino a quando vengono rilasciati o a quando viene richiamato un record
differente.
Il livello di blocco *CS assicura che altri lavori non possano leggere per l'aggiornamento un
record che è stato letto da questo lavoro. Inoltre, il programma non può leggere i record per
l'aggiornamento che sono stati bloccati con un tipo di blocco di record di *UPDATE in un altro
lavoro finché il lavoro non accede a un record differente.
Livello di blocco *ALL
Utilizzare questo valore per proteggere i record modificati e i record richiamati che sono sotto il
controllo del commit dalle modifiche apportate da altri lavori in esecuzione sotto il controllo del
commit contemporaneamente. I record richiamati o modificati sono protetti fino alla successiva
operazione di commit o rollback.
Controllo del commit
55
Il livello di blocco *ALL assicura che altri lavori non possano accedere per l'aggiornamento a un
record che è stato letto da questo lavoro. Questo è diverso dal normale protocollo di blocco.
Quando il livello di blocco è specificato come *ALL, non è possibile accedere neppure a record
che non è letto per l'aggiornamento, se è bloccato con un tipo di blocco di record di *UPDATE in
un altro lavoro.
La seguente tabella mostra la durata dei blocchi di record per i file sotto il controllo del commit, o meno.
Richiesta
Parametro LCKLVL
Durata del blocco
Tipo di blocco
Sola lettura
Nessun controllo del
commit
Nessun blocco
Nessuno
*CHG
Nessun blocco
Nessuno
*CS
Da lettura a rollback,
commit o lettura successivi
*READ
*ALL
Da lettura a commit o
rollback
*READ
Nessun controllo del
commit
Da lettura ad
aggiornamento o
cancellazione
*UPDATE
*CHG
Da lettura ad
aggiornamento o
cancellazione
*UPDATE
Lettura per aggiornamento
quindi aggiornamento o
cancellazione1
Quindi da aggiornamento o *UPDATE
cancellazione a rollback o
commit successivi2
*CS
Da lettura ad
aggiornamento o
cancellazione
*UPDATE
Quindi da aggiornamento o *UPDATE
cancellazione a rollback o
commit successivi2
*ALL
Da lettura ad
aggiornamento o
cancellazione
*UPDATE
Quindi da aggiornamento o
cancellazione a rollback o
commit successivi2
Lettura per aggiornamento
quindi rilascio1
Nessun controllo del
commit
Da lettura a rilascio
*UPDATE
*CHG
Da lettura a rilascio
*UPDATE
*CS
Da lettura a rilascio,
commit o rollback
*UPDATE
Quindi da rilascio a
rollback, commit o lettura
successivi
*UPDATE
Da lettura a rilascio,
commit o rollback
*UPDATE
*ALL
Quindi da rilascio a
rollback o commit
successivi
56
IBM i: Database Controllo del commit
Richiesta
Parametro LCKLVL
Durata del blocco
Tipo di blocco
Aggiunta
Nessun controllo del
commit
Nessun blocco
Nessuno
*CHG
Da aggiunta a commit o
rollback
*UPDATE
*CS
Da aggiunta a commit o
rollback
*UPDATE
*ALL
Da aggiunta a commit o
rollback
*UPDATE
Nessun controllo del
commit
Per la durata della scrittura *UPDATE
diretta
*CHG
Da scrittura diretta a
commit o rollback
*UPDATE
*CS
Da scrittura diretta a
commit o rollback
*UPDATE
*ALL
Da scrittura diretta a
commit o rollback
*UPDATE
Scrittura diretta
Note:
1
Se un'operazione di commit o di rollback viene eseguita dopo un'operazione di lettura per l'aggiornamento ma
prima che il record venga aggiornato, cancellato o rilasciato, il record viene sbloccato durante l'operazione di
commit o di rollback. La protezione sul record non è più disponibile appena viene completato il commit o il
rollback.
2
Se un record viene cancellato ma il commit o il rollback non è stato ancora emesso per la transazione, il record
cancellato non rimane bloccato. Se lo stesso lavoro, o uno differente, prova a leggere il record cancellato in base alla
chiave, tale lavoro riceve un'indicazione di record non trovato. Tuttavia, se esiste un percorso di accesso a chiave
univoca sul file, a un altro lavoro non è consentito inserire o aggiornare un record con lo stesso valore di chiave
univoca del record cancellato finché non sarà stato eseguito il commit della transazione.
Un tipo di blocco di record di *READ viene ottenuto sui record che non sono letti per l'aggiornamento
quando il livello di blocco è *CS o *ALL. Questo tipo di blocco impedisce ad altri lavori di leggere i
record per l'aggiornamento ma non impedisce l'accesso ai record da parte di un'operazione di sola lettura.
Un tipo di blocco di record di *UPDATE viene ottenuto sui record che vengono aggiornati, cancellati,
aggiunti o letti per l'aggiornamento. Questo tipo di blocco impedisce ad altri lavori di leggere i record per
l'aggiornamento e impedisce ai lavori in esecuzione sotto il controllo del commit con un livello di blocco
di record di *CS o *ALL di accedere ai record anche per un'operazione di sola lettura.
I programmi che non stanno utilizzando il controllo del commit possono leggere i record bloccati da un
altro lavoro ma non possono leggere i record per l'aggiornamento, indipendentemente dal valore
specificato per il parametro LCKLVL.
Il livello di blocco, specificato per una definizione di commit quando viene avviato il controllo del
commit per un gruppo di attivazione o per il lavoro, si applica solo alle aperture associate a tale specifica
definizione di commit.
Nota: i valori di livello di blocco *CS e *ALL proteggono dal richiamo di un record che ha attualmente
una modifica in sospeso da un lavoro differente. Tuttavia, i valori di livello di blocco *CS e *ALL
non proteggono dal richiamo di un record utilizzando un programma in esecuzione in un gruppo
di attivazione che attualmente ha una modifica in sospeso da un programma in esecuzione in un
gruppo di attivazione differente nello stesso lavoro.
Controllo del commit
57
Nello stesso lavoro, un programma può modificare un record che è già stato modificato nella transazione
corrente a condizione che al record si acceda nuovamente utilizzando la stessa definizione di commit.
Quando si utilizza la definizione di commit a livello di lavoro, l'accesso al record modificato può essere
eseguito da un programma in esecuzione in un gruppo di attivazione che sta utilizzando la definizione di
commit a livello di lavoro.
Concetti correlati
“Considerazioni e limitazioni per il controllo del commit” a pagina 25
È necessario tenere presente le seguenti considerazioni e limitazioni per il controllo del commit.
Riferimenti correlati
Start Commitment Control (STRCMTCTL) command
Terminazione del controllo del commit
Il comando ENDCMTCTL (Fine controllo commit) termina il controllo del commit per la definizione di
commit a livello di gruppo di attivazione o a livello di lavoro.
L'immissione del comando ENDCMTCTL indica al sistema che la definizione di commit utilizzata dal
programma che esegue la richiesta deve essere terminata. Il comando ENDCMTCTL termina una sola
definizione di commit per il lavoro e tutte le altre definizioni di commit per il lavoro rimangono
invariate.
Se la definizione di commit a livello di gruppo di attivazione viene terminata, i programmi in esecuzione
nel gruppo di attivazione non possono più apportare modifiche sotto il controllo del commit, a meno che
la definizione di commit a livello di lavoro non sia già avviata per il lavoro. Se la definizione di commit a
livello di lavoro è attiva, viene immediatamente resa disponibile per l'utilizzo da parte dei programmi in
esecuzione nel gruppo di attivazione che hanno appena terminato il controllo del commit.
Se la definizione di commit a livello di lavoro viene terminata, gli eventuali programmi in esecuzione nel
lavoro che stavano utilizzando la definizione di commit a livello di lavoro non possono più apportare
modifiche sotto il controllo del commit senza prima riavviare il controllo del commit con il comando
STRCMTCTL.
Prima di immettere il comando ENDCMTCTL, è necessario soddisfare le seguenti condizioni per la
definizione di commit da terminare:
v Devono prima essere chiusi tutti i file aperti sotto il controllo del commit per la definizione di commit
da terminare. Quando si termina la definizione di commit a livello di lavoro, l'operazione include tutti
i file aperti sotto il controllo del commit da qualsiasi programma in esecuzione in qualsiasi gruppo di
attivazione che sta utilizzando la definizione di commit a livello di lavoro.
v Devono prima essere rimosse tutte le risorse di commit API per la definizione di commit da terminare
utilizzando l'API QTNRMVCR. Quando si termina la definizione di commit a livello di lavoro, questa
operazione include tutte le risorse di commit API aggiunte da qualsiasi programma in esecuzione in
qualsiasi gruppo di attivazione che sta utilizzando la definizione di commit a livello di lavoro.
v Un database remoto associato alla definizione di commit da terminare deve essere disconnesso.
v Tutte le conversazioni protette associate alla definizione di commit devono essere terminate
normalmente utilizzando il corretto livello di sincronizzazione.
Se si sta terminando il controllo del commit in un lavoro interattivo e una o più risorse di cui è possibile
eseguire il commit associate alla definizione di commit hanno delle modifiche in sospeso, il messaggio di
interrogazione CPA8350 viene inviato all'utente richiedendo se eseguire il commit delle modifiche in
sospeso, il rollback delle modifiche in sospeso o l'annullamento della richiesta ENDCMTCTL.
Se si sta terminando il controllo del commit in un lavoro batch, e uno o più file chiusi associati alla
definizione di commit da terminare hanno ancora delle modifiche in sospeso, viene eseguito il rollback
delle modifiche e viene inviato un messaggio:
58
IBM i: Database Controllo del commit
v CPF8356 se sono registrate solo le risorse locali
v CPF835C se sono registrate solo le risorse remote
v CPF83E4 se sono registrate sia le risorse locali sia quelle remote
Se per la definizione di commit in fase di terminazione è definito un oggetto di notifica, ne potrebbe
essere eseguito l'aggiornamento.
Quando un gruppo di attivazione che ha un'API registrata come ultimo agent sta terminando, il
programma di uscita per l'API viene richiamato per ricevere la decisione di commit o di rollback. In
questo caso, anche se il gruppo di attivazione sta terminando normalmente, è comunque possibile che
una richiesta di rollback venga restituita dal programma di uscita API. È pertanto possibile che
l'operazione di commit implicito non venga eseguita.
Dopo che la definizione di commit è terminata normalmente, è stato eseguito tutto l'eventuale ripristino
necessario. Non viene eseguito alcun ripristino aggiuntivo per le risorse di commit associate alla
definizione di commit appena terminata.
Dopo che la definizione di commit è terminata, la definizione di commit a livello di gruppo di attivazione
o a livello di lavoro può essere quindi riavviata per i programmi in esecuzione nel gruppo di attivazione.
La definizione di commit a livello di lavoro può essere avviata solo se non è stata già avviata per il
lavoro.
Anche se le definizioni di commit possono essere avviate e terminate molte volte dai programmi in
esecuzione in un gruppo di attivazione, la quantità di risorse di sistema richiesta per le ripetute
operazioni di avvio e terminazione può causare una riduzione delle prestazioni del lavoro e delle
prestazioni generali del sistema. Si consiglia pertanto di lasciare attiva una definizione di commit se un
programma da richiamare successivamente ne farà uso.
Concetti correlati
“Aggiornamenti all'oggetto di notifica” a pagina 65
Il sistema aggiorna l'oggetto di notifica con l'identificazione di commit dell'ultima operazione di commit
eseguita correttamente per tale definizione di commit.
Riferimenti correlati
End Commitment Control (ENDCMTCTL) command
Terminazione avviata dal sistema del controllo del commit
Il sistema può terminare il controllo del commit oppure eseguire un'operazione di rollback o commit
implicito. A volte, la terminazione avviata dal sistema del controllo del commit è normale. Altre volte, il
controllo del commit termina con una fine lavoro o sistema anomala.
Controllo del commit durante la fine del gruppo di attivazione
Il sistema termina automaticamente una definizione di commit a livello di gruppo di attivazione quando
termina un gruppo di attivazione.
Se esistono delle modifiche in sospeso per una definizione di commit a livello di gruppo di attivazione e
il gruppo di attivazione sta terminando in modo normale, il sistema esegue un'operazione di commit
implicito per la definizione di commit prima che venga terminata. Altrimenti, un'operazione di rollback
implicito viene eseguita per la definizione di commit a livello di gruppo di attivazione prima che venga
terminata se il gruppo di attivazione sta terminando in modo anomalo o se il sistema ha rilevato degli
errori durante la chiusura di file aperti sotto il controllo del commit che erano nell'ambito del gruppo di
attivazione.
Nota: un'operazione di rollback o di commit implicito non viene mai eseguita durante l'elaborazione
della fine del gruppo di attivazione per le definizioni di commit *JOB o *DFTACTGRP. Questo è
Controllo del commit
59
dovuto al fatto che le definizioni di commit *JOB e *DFTACTGRP non vengono mai terminate
perché viene terminato un gruppo di attivazione. Queste definizioni di commit vengono invece
terminate in modo esplicito con un comando ENDCMTCTL oppure terminate dal sistema quando
termina il lavoro.
Il sistema chiude automaticamente i file che erano nell'ambito del gruppo di attivazione quando termina
il gruppo di attivazione. Questo include i file di database che erano nell'ambito del gruppo di attivazione
aperto sotto il controllo del commit. La chiusura per questo tipo di file si verifica prima dell'esecuzione di
eventuali operazioni di commit implicito per la definizione di commit a livello di gruppo di attivazione.
Pertanto, i record che non si trovano in un buffer I/E vengono forzati nel database prima che vengano
eseguite eventuali operazioni di commit implicito.
Come parte dell'operazione di rollback o commit implicito che potrebbe essere eseguita, viene fatta una
chiamata al programma di uscita di rollback o di commit API per ciascuna risorsa di commit API
associata alla definizione di commit a livello di gruppo di attivazione. Il programma di uscita deve
completare la sua elaborazione entro 5 minuti. Dopo il richiamo del programma di uscita di rollback o di
commit API, il sistema elimina automaticamente la risorsa di commit API.
Se un'operazione di rollback implicito viene eseguita per una definizione di commit che è in fase di
terminazione perché è in fase di terminazione un gruppo di attivazione, l'oggetto di notifica, se ne è
definito uno per la definizione di commit, potrebbe essere aggiornato.
Concetti correlati
“Aggiornamenti all'oggetto di notifica” a pagina 65
Il sistema aggiorna l'oggetto di notifica con l'identificazione di commit dell'ultima operazione di commit
eseguita correttamente per tale definizione di commit.
Operazioni di commit e di rollback impliciti
In alcune istanze, un'operazione di commit o di rollback viene avviata dal sistema per una definizione di
commit. Questi tipi di operazioni di commit e di rollback sono noti come richieste di commit e rollback
implicite.
Di norma, un'operazione di commit o di rollback viene avviata da un programma applicativo utilizzando
uno dei linguaggi di programmazione disponibili che supporta il controllo del commit. Questi tipi di
operazioni di commit e di rollback sono noti come richieste di commit e rollback esplicite.
Le seguenti due tabelle mostrano cosa fa il sistema quando si verificano determinati eventi correlati a una
definizione di commit che ha delle modifiche in sospeso. Una definizione di commit ha delle modifiche
in sospeso se si verifica una delle seguenti condizioni:
v Una risorsa di cui è possibile eseguire il commit è stata aggiornata.
v Un file di database aperto sotto il controllo del commit è stato letto perché la lettura di un file ne
modifica la posizione.
v La definizione di commit ha una risorsa API. Poiché le modifiche alle risorse API vengono eseguite da
un programma utente, il sistema deve presumere che tutte le risorse API abbiano delle modifiche in
sospeso.
Le voci di giornale C CM (operazione di commit) e C RB (operazione di rollback) indicano se
l'operazione era esplicita o implicita.
La seguente tabella mostra le azioni eseguite dal sistema quando un lavoro termina, in modo normale o
anomalo, sulla base delle seguenti situazioni:
v Lo stato della transazione.
v Il valore di azione in caso di fine lavoro per la definizione di commit.
v Se una risorsa API è l'ultimo agent.
60
IBM i: Database Controllo del commit
Stato
API ultimo agent
opzione Azione in
caso di fine lavoro1
RST
N/A
N/A
Operazione di commit o di rollback
Se la definizione di commit non è associata
a una transazione globale X/Open, viene
eseguito un rollback implicito.
Se la definizione di commit è associata a
una transazione globale X/Open, si
verificano i seguenti eventi:
v Se lo stato del ramo transazione non è
Attivo (S1), non viene eseguita alcuna
azione e il ramo transazione viene lasciato
nello stesso stato.
v Se lo stato del ramo transazione è Attivo
(S1), viene eseguito un rollback implicito.
PIP
N/A
N/A
Se la definizione di commit non è associata
a una transazione globale X/Open, viene
eseguito un rollback implicito.
Se la definizione di commit è associata a
una transazione globale X/Open, il ramo
transazione si trova nello stato Inattivo (S2)
e viene lasciato nello stato Inattivo (S2).
PRP
N/A
WAIT
Se la definizione di commit non è associata
a una transazione globale X/Open2, si
verifica quanto segue:
v La risincronizzazione viene avviata per
ricevere la decisione dall'iniziatore
dell'operazione di commit.
v Viene eseguita la decisione restituita di
eseguire il commit o il rollback. Viene
considerata un'operazione esplicita.
PRP
N/A
C
Se la definizione di commit non è associata
a una transazione globale X/Open2, viene
eseguita un'operazione di commit implicito.
R
Se la definizione di commit non è associata
a una transazione globale X/Open, viene
eseguita un'operazione di rollback implicito.
Se la definizione di commit è associata a
una transazione globale X/Open, si verifica
quanto segue:
v Se il lavoro che ha avviato la transazione
viene terminato, la transazione viene
lasciata in uno stato preparato finché l'XA
TM non ne esegue il commit o il rollback.
Lo stato del ramo transazione XA sarà
lasciato come Preparato (S3), in questo
caso.
v Se il lavoro del server SQL cui si sta
instradando il lavoro della transazione
viene terminato, viene eseguito in modo
implicito un rollback forzato. Lo stato del
ramo transazione XA verrà modificato in
Completato euristicamente (S5), in questo
caso.
Controllo del commit
61
Stato
API ultimo agent
opzione Azione in
caso di fine lavoro1
CIP
N/A
N/A
Viene eseguita un'operazione di commit
esplicito.
LAP
NO
WAIT
1. La risincronizzazione all'ultimo agent
viene utilizzata per richiamare la decisione
di eseguire il commit o il rollback.
Operazione di commit o di rollback
2. Viene eseguita la decisione restituita di
eseguire il commit o il rollback. Viene
considerata un'operazione esplicita.
LAP
SÌ
WAIT
1. L'API dell'ultimo agent viene richiamata
per richiamare la decisione di commit o di
rollback.
2. Viene eseguita l'operazione di commit o
di rollback. Viene considerata un'operazione
esplicita.
LAP
N/A
C
Viene eseguita un'operazione di commit
implicito.
R
Viene eseguita un'operazione di rollback
implicito.
CMT
N/A
N/A
Un'operazione di commit è già stata
completata per questa definizione di commit
ed eventuali ubicazioni successive.
L'operazione di commit è completa.
VRO
N/A
N/A
Gli agent locali e remoti hanno fornito
l'indicazione per la sola lettura. Anche tutti
gli agent successivi devono avere fornito
l'indicazione per la sola lettura. Nessuna
azione richiesta.
RBR
N/A
N/A
È richiesta un'operazione di rollback. Viene
eseguita un'operazione di rollback esplicito.
Nota:
1
È possibile modificare l'opzione Azione in caso di fine lavoro con l'API QTNCHGCO (Modifica opzioni di
commit).
2
Se la definizione di commit è associata a una transazione globale X/Open, si verificano i seguenti eventi:
v Se il lavoro che ha avviato la transazione viene terminato, la transazione viene lasciata in uno stato preparato
finché l'XA TM non ne esegue il commit o il rollback. Lo stato del ramo transazione XA sarà lasciato come
Preparato (S3), in questo caso.
v Solo per i blocchi nell'ambito della transazione, se il lavoro del server SQL cui si sta instradando il lavoro della
transazione viene terminato, viene eseguito in modo implicito un rollback forzato. Lo stato del ramo transazione
XA verrà modificato in Completato euristicamente (S5), in questo caso.
La seguente tabella mostra le azioni eseguite dal sistema quando un gruppo di attivazione termina e si
applica solo alle transazioni con dei blocchi nell'ambito del lavoro. Le azioni di sistema sono basate sui
seguenti elementi:
v Lo stato della transazione. (È sempre reimpostato (RST) quando termina un gruppo di attivazione).
v Il modo in cui termina il gruppo di attivazione: normalmente o in modo anomalo.
v Se una risorsa API è l'ultimo agent.
62
IBM i: Database Controllo del commit
Nota: se una risorsa API è registrata come ultimo agent, questo dà il controllo della decisione di
esecuzione del commit o del rollback all'ultimo agent. Il risultato della decisione è considerato
un'operazione esplicita
Stato
API ultimo agent
Tipo di terminazione
Operazione di commit o di rollback
RST
No
Normale
Viene eseguita un'operazione di commit
implicito. Se esistono delle conversazioni
protette, la definizione di commit diventerà
l'iniziatore root dell'operazione di commit.
RST
No
Anomalo
Viene eseguito un ripristino implicito.
RST
Sì
Normale
Viene richiamato il programma di uscita
API. L'operazione di commit o di rollback
viene determinata dall'API.
RST
Sì
Anomalo
Viene richiamato il programma di uscita
API. L'operazione di commit o di rollback
viene determinata dall'API.
Concetti correlati
“Controllo del commit durante la fine anomala di lavoro o sistema” a pagina 64
Il sistema termina tutte le definizioni di commit per un lavoro quando il lavoro termina in modo
anomalo. Queste definizioni di commit vengono terminate durante l'elaborazione della fine lavoro.
Questo argomento è valido solo per le definizioni di commit con i blocchi nell'ambito del lavoro.
Riferimenti correlati
Change Commitment Options (QTNCHGCO) API
Controllo del commit durante la terminazione normale del passo di
instradamento
Il sistema termina tutte le definizioni di commit per un lavoro quando un passo di instradamento viene
terminato normalmente.
Nota: le seguenti informazioni si applicano solo alle definizioni di commit con i blocchi nell'ambito del
lavoro.
Un passo di instradamento termina normalmente con una delle seguenti situazioni:
v Una terminazione normale per un lavoro batch.
v Uno scollegamento normale per un lavoro interattivo.
v Il comando RRTJOB (Reinstradamento lavoro), TFRJOB (Trasferimento lavoro) o TFRBCHJOB
(Trasferimento lavoro batch) termina il passo di instradamento corrente e avvia un nuovo passo di
instradamento.
Qualsiasi altra terminazione di un passo di instradamento è considerata anomala e viene riconosciuta in
base a un codice di completamento diverso da zero nel messaggio di completamento del lavoro CPF1164
nella registrazione lavoro.
Prima di terminare una definizione di commit durante la terminazione del passo di instradamento, il
sistema esegue un'operazione di rollback implicito se la definizione di commit ha delle modifiche in
sospeso. Questo include il richiamo del programma di uscita di rollback o di commit API per ciascuna
risorsa di commit API associata alla definizione di commit. Il programma di uscita deve completare la
sua elaborazione entro 5 minuti. Dopo il richiamo del programma di uscita di rollback o di commit API,
il sistema elimina automaticamente la risorsa di commit API.
Se per la definizione di commit è definito un oggetto di notifica, ne potrebbe essere eseguito
l'aggiornamento.
Controllo del commit
63
Concetti correlati
“Aggiornamenti all'oggetto di notifica” a pagina 65
Il sistema aggiorna l'oggetto di notifica con l'identificazione di commit dell'ultima operazione di commit
eseguita correttamente per tale definizione di commit.
Controllo del commit durante la fine anomala di lavoro o sistema
Il sistema termina tutte le definizioni di commit per un lavoro quando il lavoro termina in modo
anomalo. Queste definizioni di commit vengono terminate durante l'elaborazione della fine lavoro.
Questo argomento è valido solo per le definizioni di commit con i blocchi nell'ambito del lavoro.
Se viene terminato in modo anomalo, il sistema termina tutte le definizioni di commit che erano state
avviate e che tutti i lavori attivi stavano utilizzando quando si è verificata la fine di sistema anomala.
Queste definizioni di commit vengono terminate come parte dell'elaborazione di ripristino del database
eseguita durante il successivo IPL dopo la fine anomala di sistema.
Attenzione: il ripristino per le definizioni di commit fa riferimento a una fine anomala per il sistema o
per un lavoro dovuta a un'interruzione dell'alimentazione, un malfunzionamento hardware o un errore
nel sistema operativo o nel LIC (Licensed Internal Code - Microprogramma interno su licenza). Non si
deve utilizzare il comando ENDJOBABN (Fine anomala del lavoro) per forzare una fine anomala del
lavoro. La fine anomala può determinare un commit o un rollback parziale delle modifiche in sospeso per
le transazioni attive per il lavoro che si sta terminando. Il successivo IPL potrebbe tentare il ripristino per
le eventuali transazioni parziali per il lavoro terminato con il comando ENDJOBABN.
L'esito del ripristino del controllo del commit eseguito dal sistema durante un IPL per un lavoro
terminato con il comando ENDJOBABN è incerto. Questo è dovuto al fatto che tutti i blocchi per la
risorsa di commit vengono rilasciati quando il lavoro viene terminato in modo anomalo. Le eventuali
modifiche in sospeso dovute a transazioni parziali vengono rese disponibili ad altri lavori. Queste
modifiche in sospeso possono quindi indurre atri programmi applicativi ad apportare delle erronee
modifiche aggiuntive al database. In modo analogo, qualsiasi ripristino IPL derivante che viene eseguito
successivamente può influenzare negativamente le modifiche apportate dalle applicazioni dopo che il
lavoro è stato terminato in modo anomalo. Ad esempio, una tabella SQL potrebbe essere cancellata
durante il ripristino IPL come azione di rollback per una creazione tabella in sospeso. Tuttavia, altre
applicazioni potrebbero già avere inserito diverse righe nella tabella dopo che il lavoro è stato terminato
in modo anomalo.
Il sistema esegue le seguenti operazioni per le definizioni di commit terminate durante una fine lavoro
anomala o durante il successivo IPL dopo una fine sistema anomala:
v Prima di terminare una definizione di commit, il sistema esegue un'operazione di rollback implicito se
la definizione di commit ha delle modifiche in sospeso, a meno che l'elaborazione per la definizione di
commit non sia stata interrotta durante un'operazione di commit. Se è stata terminata durante
un'operazione di commit, la transazione potrebbe essere sottoposta a rollback, risincronizzazione o
commit, a seconda del suo stato. L'elaborazione per eseguire l'operazione di rollback implicito o per
completare l'operazione di commit include il richiamo del programma di uscita di commit e rollback
API per ciascuna risorsa di commit API associata alla definizione di commit. Dopo il richiamo del
programma di uscita di rollback o di commit API, il sistema elimina automaticamente la risorsa di
commit API.
64
IBM i: Database Controllo del commit
Attenzione: terminare il lavoro mentre una transazione è in dubbio (lo stato transazione è LAP o
PRP) può causare delle incongruenze nel database (le modifiche potrebbero essere state sottoposte a
commit su uno o più sistemi e a rollback su altri sistemi).
– Se l'opzione di commit Azione in caso di fine lavoro è COMMIT, le modifiche su questo sistema
vengono sottoposte a commit se il lavoro viene terminato, indipendentemente dal fatto che le
modifiche su altri sistemi che partecipano alla transazione vengano sottoposte a commit o a rollback.
– Se l'opzione di commit Azione in caso di fine lavoro è ROLLBACK, le modifiche su questo sistema
vengono sottoposte a rollback se il lavoro viene terminato, indipendentemente dal fatto che le
modifiche su altri sistemi che partecipano alla transazione vengono sottoposti a commit o a rollback.
– Se l'opzione di commit Azione in caso di fine lavoro è WAIT, il lavoro verrà terminato solo dopo che
sarà stata completata la risincronizzazione con il sistema proprietario della decisione di commit o di
rollback. Per fare in modo che il lavoro venga terminato prima del completamento della
risincronizzazione, è necessario eseguire un'operazione di decisione euristica e annullare la
risincronizzazione.
Si sconsiglia di terminare il lavoro o il sistema in modo anomalo durante un rollback a lunga
esecuzione. Questo causa l'esecuzione di un altro rollback quando termina il lavoro (oppure durante il
successivo IPL, se viene terminato il sistema). Il successivo rollback ripeterà il lavoro eseguito dal
rollback originario e avrà un tempo di esecuzione molto più lungo.
v Se per la definizione di commit è definito un oggetto di notifica, ne potrebbe essere eseguito
l'aggiornamento.
Se il processo termina prima che il controllo del commit venga terminato e sono ancora attive delle
conversazioni protette, potrebbe essere richiesto il commit o il rollback della definizione di commit.
L'azione è basata sull'opzione Stato e sull'opzione Azione in caso di fine lavoro per la definizione di
commit.
Concetti correlati
“Operazioni di commit e di rollback impliciti” a pagina 60
In alcune istanze, un'operazione di commit o di rollback viene avviata dal sistema per una definizione di
commit. Questi tipi di operazioni di commit e di rollback sono noti come richieste di commit e rollback
implicite.
“Aggiornamenti all'oggetto di notifica”
Il sistema aggiorna l'oggetto di notifica con l'identificazione di commit dell'ultima operazione di commit
eseguita correttamente per tale definizione di commit.
Aggiornamenti all'oggetto di notifica
Il sistema aggiorna l'oggetto di notifica con l'identificazione di commit dell'ultima operazione di commit
eseguita correttamente per tale definizione di commit.
Per gli scopi dell'oggetto di notifica, queste sono considerate modifiche di cui non è stato eseguito il
commit:
v Un aggiornamento a un record eseguito sotto il controllo del commit.
v Un record cancellato sotto il controllo del commit.
v Una modifica a livello di oggetto eseguita su un oggetto DDL locale sotto il controllo del commit.
v Un'operazione di lettura eseguita per un file di database che è stato aperto sotto il controllo del
commit. Questo è dovuto al fatto che la posizione del file viene riportata all'ultimo limite di commit
quando viene eseguita un'operazione di rollback. Se si esegue un'operazione di lettura sotto il controllo
del commit, la posizione del file viene modificata e, pertanto, esisterà una modifica di cui non è stato
eseguito il commit per la definizione di commit.
v Una definizione di commit con una delle seguenti risorse aggiunte viene sempre considerata come se
presentasse delle modifiche di cui non è stato eseguito il commit:
– Una risorsa di commit API
Controllo del commit
65
– Una risorsa DRDA * (Distributed Relational Database Architecture) remota
– Una risorsa Distributed Database Management Architecture (DDM)
– Una risorsa LU 6.2
Questo è dovuto al fatto che il sistema non sa quando una vera modifica viene apportata all'oggetto o
agli oggetti associati a questi tipi di risorse. La sezione Tipi di risorse di cui è possibile eseguire il
commit contiene maggiori informazioni su come si aggiungono e gestiscono questi tipi di risorse.
Il sistema applica gli aggiornamenti all'oggetto di notifica in base ai seguenti modi in cui può terminare
una definizione di commit:
v Se un lavoro termina normalmente e non esistono modifiche di cui non è stato eseguito il commit, il
sistema non inserisce l'identificazione di commit dell'ultima operazione di commit eseguita
correttamente nell'oggetto di notifica.
v Se viene eseguita un'operazione di commit implicito per una definizione di commit a livello di gruppo
di attivazione quando viene terminato il gruppo di attivazione, il sistema non inserisce l'identificazione
di commit dell'ultima operazione di commit eseguita correttamente nell'oggetto di notifica.
v
v
v
v
Nota: le operazioni di commit implicite non vengono mai eseguite per la definizione di commit
*DFTACTGRP o *JOB
Se il sistema, il lavoro o un gruppo di attivazione termina in modo anomalo prima della prima
operazione di commit eseguita correttamente per una definizione di commit, il sistema non aggiorna
l'oggetto di notifica perché non c'è alcuna identificazione di ultimo commit. Per distinguere tra questa
condizione e un completamento di programma normale, il programma deve aggiornare l'oggetto di
notifica con una specifica voce prima di completare la prima operazione di commit eseguita
correttamente per la definizione di commit.
Se si verifica una fine lavoro anomala o una terminazione di sistema anomala dopo almeno
un'operazione di commit eseguita correttamente, il sistema inserisce l'identificazione di commit di tale
operazione di commit nell'oggetto di notifica. Se l'ultima operazione di commit eseguita correttamente
non specificava un'identificazione di commit, l'oggetto di notifica non viene aggiornato. Per una fine
lavoro anomala, questa elaborazione di oggetto di notifica viene eseguita per ciascuna definizione di
commit che era attiva per il lavoro. Per una terminazione di sistema anomala, questa elaborazione di
oggetto di notifica viene eseguita per ciascuna definizione di commit che era attiva per tutti i lavori sul
sistema.
Il sistema aggiorna l'oggetto di notifica con l'identificazione di commit dell'ultima operazione di
commit eseguita correttamente per tale definizione di commit se si verificano tutti gli eventi qui di
seguito indicati:
– Viene terminato un gruppo di attivazione non predefinito.
– Un'operazione di rollback implicito viene eseguita per la definizione di commit a livello di gruppo
di attivazione.
– Almeno un'operazione di commit eseguita correttamente è stata eseguita per tale definizione di
commit.
Se l'ultima operazione di commit eseguita correttamente non specificava un'identificazione di commit,
l'oggetto di notifica non viene aggiornato. Un'operazione di rollback implicito viene eseguita per una
definizione di commit a livello di gruppo di attivazione se il gruppo di attivazione sta terminando in
modo anomalo o se si sono verificati degli errori durante la chiusura dei file che erano stati aperti sotto
il controllo del commit e che erano nell'ambito di tale gruppo di attivazione. Per ulteriori informazioni
sull'inclusione dei file di database nell'ambito di gruppi di attivazione e sul modo in cui possono essere
terminati i gruppi di attivazione, consultare il manuale di riferimento per il linguaggio ILE che si sta
utilizzando.
Se esistono delle modifiche di cui non è stato eseguito il commit quando un lavoro termina in modo
normale ed è stata eseguita almeno un'operazione di commit correttamente, l'identificazione di commit
dell'ultima operazione di commit eseguita correttamente viene inserita nell'oggetto di notifica e viene
eseguito il rollback delle modifiche di cui non è stato eseguito il commit. Se l'ultima operazione di
commit eseguita correttamente non specificava un'identificazione di commit, l'oggetto di notifica non
66
IBM i: Database Controllo del commit
viene aggiornato. Questa elaborazione di oggetto di notifica viene eseguita per ciascuna definizione di
commit che era attiva per il lavoro quando il lavoro è stato terminato.
v Se esistono delle modifiche di cui non è stato eseguito il commit quando viene eseguito il comando
ENDCMTCTL, l'oggetto di notifica viene aggiornato solo se l'ultima operazione di commit eseguita
correttamente specificava un'identificazione di commit:
– Per un lavoro batch, viene eseguito il rollback delle modifiche di cui non è stato eseguito il commit e
l'identificazione di commit dell'ultima operazione di commit eseguita correttamente viene inserita
nell'oggetto di notifica.
– Per un lavoro interattivo, se la risposta al messaggio di interrogazione CPA8350 è l'esecuzione del
rollback delle modifiche, viene eseguito il rollback delle modifiche di cui non è stato eseguito il
commit e l'identificazione di commit dell'ultima operazione di commit eseguita correttamente viene
inserita nell'oggetto di notifica.
– Per un lavoro interattivo, se la risposta al messaggio di interrogazione CPA8350 è l'esecuzione del
commit delle modifiche, il sistema chiede un'identificazione di commit da utilizzare e viene eseguito
il commit delle modifiche. L'identificazione di commit immessa sul pannello di richiesta viene
inserita nell'oggetto di notifica.
– Per un lavoro interattivo, se la risposta al messaggio di interrogazione CPA8350 è l'annullamento
della richiesta ENDCMTCTL, le modifiche in sospeso restano e l'oggetto di notifica non viene
aggiornato.
Concetti correlati
“Terminazione del controllo del commit” a pagina 58
Il comando ENDCMTCTL (Fine controllo commit) termina il controllo del commit per la definizione di
commit a livello di gruppo di attivazione o a livello di lavoro.
“Controllo del commit durante la fine del gruppo di attivazione” a pagina 59
Il sistema termina automaticamente una definizione di commit a livello di gruppo di attivazione quando
termina un gruppo di attivazione.
“Controllo del commit durante la terminazione normale del passo di instradamento” a pagina 63
Il sistema termina tutte le definizioni di commit per un lavoro quando un passo di instradamento viene
terminato normalmente.
“Controllo del commit durante la fine anomala di lavoro o sistema” a pagina 64
Il sistema termina tutte le definizioni di commit per un lavoro quando il lavoro termina in modo
anomalo. Queste definizioni di commit vengono terminate durante l'elaborazione della fine lavoro.
Questo argomento è valido solo per le definizioni di commit con i blocchi nell'ambito del lavoro.
“Tipi di risorse di cui è possibile eseguire il commit” a pagina 12
Questa tabella elenca i tipi differenti di risorse di cui è possibile eseguire il commit, inclusi FILE, DDL
(Data Definition Language), DDM (distributed data management), LU (logical unit) 6.2, DRDA
(Distributed Relational Database Architecture, API e TCP.
“Oggetto di notifica del commit” a pagina 53
Un oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioni
che identificano l'ultima transazione eseguita correttamente completata per una specifica definizione di
commit se tale definizione di commit non è stata terminata normalmente.
Ripristino del controllo del commit durante l'IPL (initial program load)
dopo la fine anomala
Quando si esegue un IPL (initial program load) dopo la fine anomala del sistema, il sistema prova a
ripristinare tutte le definizioni di commit che erano attive quando il sistema è stato terminato.
In modo analogo, quando si attiva un lotto dischi indipendente, il sistema prova a ripristinare tutte le
definizioni di commit correlate a tale lotto dischi indipendente che erano attive quando è stato disattivato
o terminato in modo anomalo.
Controllo del commit
67
Il ripristino viene eseguito dai lavori del server di database avviati dal sistema durante l'IPL. I lavori del
server di database vengono avviati dal sistema per gestire le operazioni che non possono o non devono
essere eseguite da altri lavori.
I lavori del server di database sono denominati QDBSRVnn, dove nn è un numero di due cifre. Il numero
di lavori del server di database dipende dalla dimensione del sistema. In modo analogo, il nome del
lavoro del server di database per un lotto dischi indipendente o un gruppo di lotti dischi indipendenti è
QDBSxxxVnn, dove xxx è il numero di lotto dischi indipendente e nn è un numero di due cifre. Ad
esempio, QDBS035V02 può essere il nome del lavoro del server di database per il lotto dischi
indipendente 35.
La sezione Stati della transazione per il controllo del commit in due fasi mostra le azioni eseguite dal
sistema, a seconda dello stato della transazione quando si è verificato il malfunzionamento. Per due stati,
PRP e LAP, l'azione di sistema è in dubbio.
Note:
v Le seguenti informazioni si applicano solo alle definizioni di commit con i blocchi nell'ambito
del lavoro.
v Il gestore transazioni ripristina le definizioni di commit associate alle transazioni XA (sia se i
loro blocchi sono nell'ambito del lavoro sia se sono nell'ambito della transazione) utilizzando le
API XA, non il processo di risincronizzazione descritto in questo argomento.
Il sistema non può determinare cosa fare finché non esegue la risincronizzazione con le altre ubicazioni
che partecipano alla transazione. Questa risincronizzazione viene eseguita dopo il completamento dell'IPL
o dell'operazione di attivazione.
Il sistema utilizza i lavori del server di database per eseguire questa risincronizzazione. Le definizioni di
commit che devono essere ripristinate sono associate ai lavori del server di database. Durante l'IPL, il
sistema acquisisce tutti i blocchi di record e gli altri blocchi di oggetti che erano detenuti dalla definizione
di commit prima della terminazione del sistema. Questi blocchi sono necessari per proteggere le risorse di
commit locali finché la risincronizzazione non è completa ed è possibile eseguire il commit o il rollback
delle risorse.
I messaggi vengono inviati alle registrazioni lavoro dei lavori del server di database per indicare lo stato
della risincronizzazione con le ubicazioni remote. Se la transazione è in dubbio, la risincronizzazione deve
essere completata con l'ubicazione proprietaria della decisione per la transazione prima che le risorse
locali possano essere sottoposte a commit o a rollback.
Quando viene presa la decisione per una transazione, i seguenti messaggi potrebbero essere inviati alla
registrazione lavoro per il lavoro del server di database.
CPI8351
Si sta eseguendo il rollback di &1 modifiche in sospeso
CPC8355
Ripristino post-IPL della definizione di commit &8 per il lavoro &19/&18/&17 completato.
CPD835F
Il ripristino IPL della definizione di commit &8 per il lavoro &19/&18/&17 ha avuto esito
negativo,
Possono essere inviati anche altri messaggi correlati al ripristino. Questi messaggi vengono inviati alla
registrazione cronologica (QHST). Se si verificano degli errori, dei messaggi vengono inviati anche alla
coda messaggi QSYSOPR.
È possibile determinare l'avanzamento del ripristino utilizzando System i Navigator, visualizzando la
registrazione lavoro per il lavoro del server di database oppure utilizzando il comando WRKCMTDFN
68
IBM i: Database Controllo del commit
(Gestione definizioni di commit). Anche se con System i Navigator e la visualizzazione Gestione
definizioni di commit è possibile forzare il sistema ad eseguire il commit o il rollback, è necessario
ricorrere a questa operazione solo quando non ci sono alternative. Se si prevede che tutte le ubicazioni
che hanno partecipato alla transazione verranno eventualmente restituite allo stato operativo, è necessario
consentire ai sistemi di risincronizzarsi. Questo assicura l'integrità dei database.
Concetti correlati
“Considerazioni sui lotti dischi indipendenti per le definizioni di commit” a pagina 22
Quando si utilizzano i lotti dischi indipendenti, è necessario tenere presenti le seguenti considerazioni per
le definizioni di commit.
“Stati della transazione per il controllo del commit a due fasi” a pagina 31
Una definizione di commit viene stabilita su ciascuna ubicazione che fa parte della rete del programma di
transazione. Per ciascuna definizione di commit, il sistema tiene traccia dello stato della sua transazione
corrente e della transazione precedente.
Gestione di transazioni e controllo del commit
Utilizzando queste istruzioni, è possibile visualizzare le informazioni di controllo del commit e
ottimizzare le prestazioni per il controllo del commit.
Visualizzazione delle informazioni sul controllo del commit
System i Navigator può visualizzare informazioni su tutte le transazioni (unità di lavoro logiche) sul
sistema. System i Navigator può anche visualizzare eventuali informazioni sul lavoro associate a una
transazione.
Nota: queste operazioni di visualizzazione non visualizzano il livello di isolamento per le applicazioni
SQL.
Per visualizzare le informazioni, procedere nel seguente modo:
1. Da System i Navigator, espandere il sistema che si desidera utilizzare.
2. Espandere Database.
3. Espandere il sistema che si desidera gestire.
4. Espandere Transazioni.
Nota: per visualizzare una transazione associata a una transazione globale X/Open, espandere
Transazioni globali. Per visualizzare una transazione gestita da DB2, espandere Transazioni
database.
5. Espandere Transazioni globali o Transazioni database.
Questa visualizzazione mostra le seguenti informazioni:
v ID unità di lavoro
v Stato unità di lavoro
v Lavoro
v
v
v
v
Utente
Numero
Risincronizzazione in corso
Definizione di commit
La guida in linea fornisce informazioni su tutte le visualizzazioni di stato e sui campi contenuti in
ciascuna visualizzazione.
Controllo del commit
69
Attività correlate
“Rilevazione di condizioni di stallo” a pagina 115
Una condizione di stallo può verificarsi quando un lavoro detiene un blocco su un oggetto, l'oggetto A, e
sta attendendo di ottenere un blocco su un altro oggetto, l'oggetto B. Contemporaneamente, un altro
lavoro o un'altra transazione attualmente detiene un blocco sull'oggetto B e sta attendendo di ottenere un
blocco sull'oggetto A.
“Ripristino delle transazioni dopo un errore nelle comunicazioni” a pagina 116
Queste istruzioni aiutano a gestire le transazioni che eseguono delle attività su un sistema remoto dopo
che si è verificato un errore nelle comunicazioni con tale sistema.
“Quando forzare le opzioni di commit e di rollback e quando annullare la risincronizzazione” a pagina
117
La decisione di forzare un'operazione di commit o di rollback viene detta decisione euristica. Questa azione
abilita un operatore ad eseguire il commit o il rollback manualmente delle risorse per una transazione che
è in uno stato Preparato.
“Ricerca di transazioni di grandi dimensioni oppure obsolete” a pagina 119
Utilizzare il comando WRKCMTDFN (Gestione definizioni di commit) per trovare transazioni di grandi
dimensioni oppure obsolete.
Visualizzazione di oggetti bloccati per una transazione
È possibile visualizzare degli oggetti bloccati per le transazioni globali solo con i blocchi nell'ambito della
transazione.
Per visualizzare gli oggetti bloccati per una transazione, attenersi alla seguente procedura:
1. Da System i Navigator, espandere il sistema che si desidera utilizzare.
2. Espandere Database.
3. Espandere il sistema che si desidera gestire.
4. Espandere Transazioni.
5. Espandere Transazioni globali.
6. Fare clic con il tasto destro del mouse sulla transazione che si desidera gestire e selezionare Oggetti
bloccati.
Attività correlate
“Rilevazione di condizioni di stallo” a pagina 115
Una condizione di stallo può verificarsi quando un lavoro detiene un blocco su un oggetto, l'oggetto A, e
sta attendendo di ottenere un blocco su un altro oggetto, l'oggetto B. Contemporaneamente, un altro
lavoro o un'altra transazione attualmente detiene un blocco sull'oggetto B e sta attendendo di ottenere un
blocco sull'oggetto A.
Visualizzazione di lavori associati a una transazione
Per visualizzare i lavori associati a una transazione, attenersi alla seguente procedura.
1.
2.
3.
4.
5.
6.
Dalla finestra System i Navigator, espandere il sistema che si desidera utilizzare.
Espandere Database.
Espandere il sistema che si desidera gestire.
Espandere Transazioni.
Espandere Transazioni globali o Transazioni database.
Fare clic con il tasto destro del mouse sulla transazione che si desidera gestire e selezionare Lavori.
Per le transazioni del database e quelle globali, con blocchi di lavori aperti, viene visualizzato un elenco
di lavori associati alla transazione.
Per transazioni globali con blocchi nell'ambito della transazione, viene visualizzato un elenco di lavori a
cui è collegato questo oggetto transazione o che sono in attesa del collegamento con questo oggetto
transazione
70
IBM i: Database Controllo del commit
Attività correlate
“Rilevazione di condizioni di stallo” a pagina 115
Una condizione di stallo può verificarsi quando un lavoro detiene un blocco su un oggetto, l'oggetto A, e
sta attendendo di ottenere un blocco su un altro oggetto, l'oggetto B. Contemporaneamente, un altro
lavoro o un'altra transazione attualmente detiene un blocco sull'oggetto B e sta attendendo di ottenere un
blocco sull'oggetto A.
Visualizzazione dello stato risorsa di una transazione
Per visualizzare lo stato risorsa di una transazione, attenersi alla seguente procedura.
1. Dalla finestra System i Navigator, espandere il sistema che si desidera utilizzare.
2. Espandere Database.
3. Espandere il sistema che si desidera gestire.
4. Espandere Transazioni.
5. Espandere Transazioni globali o Transazioni database.
6. Fare clic con il tasto destro del mouse sulla transazione che si desidera gestire e selezionare Stato
risorsa.
Visualizzazione delle proprietà delle transazioni
Per visualizzare le proprietà delle transazioni, attenersi alla seguente procedura.
1. Dalla finestra System i Navigator, espandere il sistema che si desidera utilizzare.
2.
3.
4.
5.
6.
Espandere Database.
Espandere il sistema che si desidera gestire.
Espandere Transazioni.
Espandere Transazioni globali o Transazioni database.
Fare clic con il tasto destro del mouse sulla transazione che si desidera gestire e selezionare Proprietà.
Ottimizzazione delle prestazioni per il controllo del commit
L'utilizzo del controllo del commit richiede delle risorse che possono influenzare le prestazioni del
sistema. Diversi fattori influenzano le prestazioni del sistema relativamente al controllo del commit.
Un fattore che non influenza le prestazioni
Aprire un file
Se si apre un file senza specificare l'opzione di apertura del commit, non viene utilizzata alcuna
risorsa di sistema aggiuntiva, anche se è stata avviata una definizione di commit. Per ulteriori
informazioni sulla specifica dell'opzione di apertura del commit, consultare l'appropriato manuale
di riferimento HLL (high-level language).
Fattori che riducono le prestazioni
Giornale
La registrazione su giornale di un file richiede delle risorse di sistema. Tuttavia, nella maggior
parte dei casi, la registrazione su giornale ha prestazioni migliori con il controllo del commit che
senza il controllo del commit. Se si specificano solo immagini-successive, il controllo del commit
modifica questa specifica indicando sia immagini-precedenti sia immagini-successive mentre è
effettivo il controllo del commit. Questa è di norma una considerazione relativa allo spazio, non
alle prestazioni.
Operazione di commit
Se sono state apportate delle modifiche alle risorse registrate su giornale durante la transazione,
ogni commit di una transazione aggiunge due voci a ciascun giornale correlato a queste risorse. Il
numero di voci aggiunte può aumentare in modo significativo per un volume elevato di piccole
transazioni. È possibile inserire i ricevitori di giornale in un lotto dischi separato rispetto ai
giornali.
Controllo del commit
71
Operazione di rollback
Poiché il controllo del commit deve eseguire il rollback delle modifiche in sospeso registrate nel
database, sono richieste delle risorse di sistema aggiuntive quando si verifica un rollback. Inoltre,
se delle modifiche di record sono in sospeso, un'operazione di rollback causa l'aggiunta di voci
aggiuntive al giornale.
Comandi STRCMTCTL (Avvio controllo commit) e ENDCMTCTL (Fine controllo commit)
Per il sistema si verifica un sovraccarico aggiuntivo ogni volta che una definizione di commit
viene avviata utilizzando il comando STRCMTCTL e viene terminata utilizzando il comando
ENDCMTCTL. Evitare di utilizzare i comandi STRCMTCTL e ENDCMTCTL per ciascuna
transazione. Utilizzarli sono quando necessario. È possibile stabilire una definizione di commit
all'inizio di un lavoro interattivo e utilizzarla per la durata del lavoro.
Utilizzare più di un giornale per le transazioni di controllo del commit.
Con il commit in due fasi, i file aperti sotto il controllo del commit possono essere registrati su
giornale in più di un giornale. Tuttavia, l'utilizzo di più di un giornale richiede delle risorse di
sistema aggiuntive per gestire la definizione di commit. L'utilizzo di più di un giornale può anche
rendere il ripristino più complicato.
Blocco di record
Il blocco di record può interessare altre applicazioni. Il numero di record bloccati in uno specifico
lavoro aumenta le risorse di sistema globali utilizzate per il lavoro. Le applicazioni che devono
accedere allo stesso record devono attendere la fine della transazione.
Richiedere SEQONLY(*YES)
Se si richiede l'opzione SEQONLY(*YES) (utilizzando il comando OVRDBF oppure il programma
applicativo prova implicitamente a utilizzare SEQONLY(*YES)) e il file viene aperto solo per
l'immissione sotto il controllo del commit con LCKLVL(*ALL), l'opzione viene modificata in
SEQONLY(*NO). Questa opzione può influenzare le prestazioni dei file di immissione perché i
record non verranno bloccati.
Richiedere una modifica a livello di record per un file di database quando è attiva l'elaborazione di
salvataggio durante l'utilizzo o di attesa IASP (Independent ASP)
Una richiesta per eseguire una modifica a livello di record sotto il controllo del commit per un
file di database potrebbe essere ritardata se la definizione di commit è a un limite di commit e
un'operazione di salvataggio durante l'utilizzo o di attesa IASP (Independent ASP) è in
esecuzione in un lavoro differente. Per l'operazione di salvataggio durante l'utilizzo, questo può
verificarsi quando un file viene registrato su giornale sullo stesso giornale di alcuni degli oggetti
nella richiesta di salvataggio.
Nota: la colonna Stato del comando WRKACTJOB (Gestione lavori attivi) visualizza CMTW (in
attesa di commit) quando un lavoro è congelato per l'elaborazione del checkpoint del
salvataggio durante l'utilizzo.
Modifiche di commit o rollback quando l'elaborazione di salvataggio durante l'utilizzo o di attesa
IASP (Independent ASP) è attiva
Un'operazione di commit o di rollback può essere ritardata a un limite di commit quando
un'operazione di salvataggio durante l'utilizzo o di attesa IASP (Independent ASP) è in
esecuzione in un lavoro differente. Questo può verificarsi quando una risorsa di commit API è
stata precedentemente aggiunta alla definizione di commit, a meno che non si verifichi una delle
seguenti condizioni:
v Per l'operazione di salvataggio durante l'utilizzo, la risorsa API è stata aggiunta utilizzando
l'API (Aggiunta risorsa di commit) e il campo che indica che è consentita la normale
elaborazione di salvataggio ha un valore di Y.
v Per l'operazione di attesa dell'IASP (Independent ASP), la risorsa API è stata aggiunta
utilizzando l'API QTNADDCR e il campo Concessione stato di attesa IASP ha un valore di Y.
Poiché il lavoro viene detenuto durante la richiesta di commit o di rollback e poiché una richiesta
di commit o di rollback può essere eseguita solo per una singola definizione di commit per volta,
72
IBM i: Database Controllo del commit
i lavori con più di una definizione di commit con le risorse di commit API possono impedire il
completamento di un'operazione di salvataggio durante l'utilizzo o di attesa dell'IASP
(Independent ASP).
Nota: se si utilizza il nuovo salvataggio con la funzione di transazioni parziali, l'oggetto può
essere salvato senza terminare una definizione di commit.
Richiedere una modifica a livello di oggetto quando l'elaborazione di salvataggio durante l'utilizzo o
di attesa IASP (Independent ASP) è attiva
Una richiesta per eseguire una modifica a livello di oggetto sotto il controllo del commit potrebbe
essere ritardata se la definizione di commit è a un limite di commit e un'operazione di
salvataggio durante l'utilizzo o di attesa IASP (Independent ASP) è in esecuzione in un lavoro
differente. Questo può verificarsi quando viene eseguita una modifica a livello di oggetto mentre
l'operazione di salvataggio durante l'utilizzo o di attesa dell'IASP (Independent ASP) è in
esecuzione sulla libreria che contiene l'oggetto. Ad esempio, l'operazione di creazione della tabella
SQL sotto il controllo del commit per la tabella MYTBL nella libreria MYSQLLIB potrebbe essere
ritardata quando un'operazione di salvataggio durante l'utilizzo o di attesa dell'IASP
(Independent ASP) è in esecuzione sulla libreria MYSQLLIB.
Nota: se il tempo di attesa supera i 60 secondi, viene inviato il messaggio di interrogazione
CPA8351 per chiedere all'utente se continuare l'attesa o se annullare l'operazione.
Aggiungere una risorsa API utilizzando l'API QTNADDCR
Una richiesta di aggiungere una risorsa di commit API utilizzando l'API QTNADDCR potrebbe
essere ritardata se tutte le definizioni di commit per il lavoro sono a un limite di commit e
un'operazione di salvataggio durante l'utilizzo o di attesa dell'IASP (Independent ASP) è in
esecuzione in un lavoro differente.
Note:
1. Se il tempo di attesa supera i 60 secondi, viene inviato il messaggio di interrogazione
CPA8351 per chiedere all'utente se continuare l'attesa o se annullare l'operazione.
2. Per l'operazione di salvataggio durante l'utilizzo, questo non si applica alle risorse API
che erano state aggiunte utilizzando l'API QTNADDCR se il campo che indica che è
consentita la normale elaborazione di salvataggio ha un valore di Y. Per l'operazione di
attesa dell'IASP (Independent ASP), questo non si applica alle risorse API che erano
state aggiunte utilizzando l'API QTNADDCR se il campo Concessione stato di attesa
IASP ha un valore di Y.
Fattori che migliorano le prestazioni
Utilizzare un giornale predefinito
L'utilizzo di un giornale predefinito può migliorare le prestazioni se si chiudono e riaprono tutti i
file sotto il controllo del commit mentre la definizione di commit è attiva. Tuttavia, l'utilizzo di un
giornale predefinito con OMTJRNE(*NONE) riduce le prestazioni delle operazioni di commit e
rollback.
Selezionare un ultimo agent
Le prestazioni vengono migliorate quando viene selezionato un ultimo agent, in quanto è
richiesto un numero minore di interazioni tra il sistema e l'ultimo agent durante un'operazione di
commit. Tuttavia, se si verifica un errore nelle comunicazioni durante un'operazione di commit,
l'operazione di commit non verrà completata finché non sarà stata completata la
risincronizzazione, indipendentemente dal valore dell'opzione Attesa risultato. Questo tipo di
errore è raro ma questa opzione consente allo scrittore dell'applicazione di considerare l'impatto
negativo derivante dal causare all'utente un'attesa indefinita del completamento della
risincronizzazione quando si verifica un errore. Valutare quanto detto rapportandolo al
miglioramento delle prestazioni fornito dall'ottimizzazione dell'ultimo agent durante delle
Controllo del commit
73
operazioni di commit eseguite correttamente. Questa considerazione è generalmente più
significativa per i lavori interattivi che per i lavori batch.
Il valore predefinito prevede che è consentito che un ultimo agent venga selezionato dal sistema
ma l'utente può modificare questo valore utilizzando l'API QTNCHGCO.
Non utilizzare l'opzione Attesa risultato
Quando le risorse remote sono sotto il controllo del commit, le esecuzioni sono migliorate quando
l'opzione Attesa risultato è impostata su N (No) e tutti i sistemi remoti supportano la presunta
fine anomala. L'opzione Attesa risultato è impostata su No dal sistema per l'applicazione DDM e
DRDA quando la prima connessione viene stabilita con un sistema remoto. Le applicazioni APPC
devono impostare esplicitamente l'opzione Attesa risultato, altrimenti verrà utilizzato il valore
predefinito di Y.
Selezionare l'opzione OK tralasciare
Le prestazioni sono migliorate quando viene selezionata l'opzione OK tralasciare.
Selezionare l'opzione Per sola lettura
Le prestazioni sono migliorate quando è selezionata l'opzione Per sola lettura.
Concetti correlati
Journal management
“Definizione di commit per un commit in due fasi: indicazione di OK tralasciare” a pagina 41
Di norma, il gestore transazioni in qualsiasi ubicazione nella rete del programma di transazione partecipa
a ogni operazione di commit o di rollback. Per migliorare le prestazioni, è possibile configurare qualcuna
o tutte le ubicazioni in una transazione per consentire al gestore transazioni di indicare che è OK
tralasciare.
“Definizione di commit per un commit in due fasi: consentire VRO (vote read-only)” a pagina 35
Di norma, un gestore transazioni partecipa a entrambe le fasi dell'elaborazione di commit. Per migliorare
le prestazioni dell'elaborazione di commit, è possibile configurare qualcuna delle ubicazioni, oppure tutte,
in una transazione per consentire al gestore transazioni di eseguire il VRO (vote read-only).
Informazioni correlate
Add Commitment Resource (QTNADDCR) API
Riduzione al minimo dei blocchi
Un modo tipico per ridurre al minimo i blocchi di record consiste nel rilasciare il blocco di record.
(Questa tecnica non funziona se è stato specificato LCKLVL(*ALL)).
Viene qui di seguito riportato un esempio di riduzione al minimo di blocchi di record rilasciando il
blocco di record. Una singola applicazione di gestione dei file di norma si attiene alla seguente procedura:
1. Visualizzare una richiesta per un'identificazione di record da modificare.
2. Richiamare il record richiesto.
3. Visualizzare il record.
4. Consentire all'utente della stazione di lavoro di apportare la modifica.
5. Aggiornare il record.
Nella maggior parte dei casi, il record è bloccato dall'accesso del record richiesto tramite l'aggiornamento.
Il tempo di attesa del record potrebbe essere superato per un altro lavoro che sta attendendo il record.
Per evitare di bloccare un record mentre l'utente della stazione di lavoro sta considerando una modifica,
rilasciare il record dopo che è stato richiamato dal database (prima che compaia la visualizzazione del
record). Occorre quindi accedere nuovamente al record prima dell'aggiornamento. Se il record è stato
modificato tra la data/ora in cui è stato rilasciato e quella in cui è stato nuovamente effettuato l'accesso
ad esso, è necessario informare l'utente della stazione di lavoro. Il programma può determinare se il
record è stato modificato salvando uno o più campi del record originale e confrontandoli con i campi
nello stesso record dopo che ne è stato eseguito il richiamo nel seguente modo:
74
IBM i: Database Controllo del commit
v Utilizzare un campo di conteggio degli aggiornamenti nel record e aggiungere 1 al campo
immediatamente prima di un aggiornamento. Il programma salva il valore originale e lo confronta con
il valore nel campo quando il record viene richiamato nuovamente. Se si è verificata una modifica,
l'utente della stazione di lavoro viene informato e viene visualizzato nuovamente il record. Il campo di
conteggio degli aggiornamenti viene modificato solo se si verifica un aggiornamento. Il record viene
rilasciato mentre l'utente della stazione di lavoro sta considerando una modifica. Se si utilizza questa
tecnica, è necessario utilizzarla in ogni programma che aggiorna il file.
v Salvare il contenuto dell'intero record di dati e confrontarlo con il record la volta successiva che viene
richiamato.
In entrambi i casi precedenti, la sequenza di operazioni impedisce il semplice utilizzo di dati descritti
esternamente in RPG dove gli stessi nomi di campo vengono utilizzati nel record master e nel file video.
L'utilizzo degli stessi nomi di campo (in RPG) non funziona perché le modifiche dell'utente della stazione
di lavoro vengono sovrapposte quando il record viene richiamato nuovamente. È possibile risolvere
questo problema spostando i dati di record in una struttura di dati. In alternativa, se si utilizza la parola
chiave DDS, RTNDTA, è possibile continuare a utilizzare i dati descritti esternamente. La parola chiave
RTNDTA consente al programma di leggere nuovamente i dati sul pannello senza che il sistema
operativo debba spostare i dati dalla visualizzazione al programma. Questo consente al programma di
effettuare le seguenti attività:
1. Richiedere l'identificazione del record.
2. Richiamare il record richiesto dal database.
3. Rilasciare il record.
4. Salvare il campo o i campi utilizzati per determinare se il record è stato modificato.
5. Visualizzare il record e attendere che l'utente della stazione di lavoro risponda.
Se l'utente della stazione di lavoro modifica il record nella visualizzazione, il programma utilizza la
seguente sequenza:
1. Richiamare nuovamente il record dal database.
2. Mettere a confronto i campi salvati per determinare se il record di database è stato modificato. Se è
stato modificato, il programma rilascia il record e invia un messaggio quando il record viene
visualizzato.
3. Richiamare il record dalla visualizzazione eseguendo un'operazione di lettura con la parola chiave
RTNDTA e aggiornare il record nel record di database.
4. Procedere alla successiva richiesta logica perché non ci sono record aggiuntivi da rilasciare se l'utente
della stazione di lavoro annulla la richiesta.
LCKLVL(*CHG) e LCKLVL(*CS) funzionano in questa situazione. Se viene utilizzato LCKLVL(*ALL), è
necessario rilasciare il blocco di record utilizzando un'operazione di commit o di rollback.
Attività correlate
“Rilevazione di condizioni di stallo” a pagina 115
Una condizione di stallo può verificarsi quando un lavoro detiene un blocco su un oggetto, l'oggetto A, e
sta attendendo di ottenere un blocco su un altro oggetto, l'oggetto B. Contemporaneamente, un altro
lavoro o un'altra transazione attualmente detiene un blocco sull'oggetto B e sta attendendo di ottenere un
blocco sull'oggetto A.
Gestione della dimensione della transazione
Un altro modo per ridurre al minimo i blocchi di record consiste nel gestire la dimensione della
transazione.
Per questa discussione, una transazione è interattiva. (Il controllo del commit può anche essere utilizzato
per le applicazioni batch, che spesso possono essere considerate una serie di transazioni). Molte delle
stesse considerazioni sono valide per le applicazioni batch, che sono discusse nella sezione Controllo del
commit per le applicazioni batch.
Controllo del commit
75
|
|
|
|
|
|
|
|
|
|
|
|
È possibile bloccare un massimo di 500 000 000 record durante una transazione per ciascun giornale
associato alla transazione. È possibile ridurre questo limite utilizzando un file delle opzioni query
(QAQQINI). Utilizzare il parametro QRYOPTLIB del comando CHGQRYA (Modifica attributi query) per
specificare un file delle opzioni query che può essere utilizzato da un lavoro. Utilizzare il valore
COMMITMENT_CONTROL_LOCK_LEVEL nel file delle opzioni query come limite di blocco per il
lavoro. Il valore del limite di blocco viene memorizzato internamente nella cache per ciascuna definizione
di commit la prima volta che una risorsa registrata su giornale viene posta sotto il controllo del commit.
Se il limite di blocco viene modificato dopo tale punto, il valore memorizzato nella cache deve essere
aggiornato perché diventi effettivo per tale definizione di commit. Qualsiasi chiamata dell'API di
richiamo di informazioni di commit QTNRCMTI aggiorna il valore memorizzato nella cache nel lavoro
chiamante. Il nuovo valore non si applicherà alle transazioni avviate prima dell'aggiornamento della
cache.
Quando si sceglie il livello di blocco per i record, prendere in considerazione la dimensione delle
transazioni. Utilizzare la dimensione per determinare per quanto tempo i record sono bloccati prima che
termini una transazione. È necessario decidere se un'operazione di commit o di rollback per il controllo
del commit è limitata a un singolo utilizzo del tasto Invio o se la transazione consiste in molti utilizzi del
tasto Invio.
Nota: più breve è la transazione e prima il lavoro in attesa di avviare l'elaborazione del checkpoint di
salvataggio durante l'utilizzo può continuare ed essere completato.
Ad esempio, per un'applicazione di immissione di ordini, un cliente può ordinare vari articoli in un
singolo ordine richiedendo un record di dettaglio ordine e un aggiornamento del record master di
inventario per ogni articolo nell'ordine. Se la transazione è definita come l'intero ordine e ciascun utilizzo
del tasto Invio ordina un articolo, tutti i record coinvolti nell'ordine sono bloccati per la durata dell'intero
ordine. Pertanto, i record utilizzati frequentemente (come ad esempio i record master di inventario)
possono essere bloccati per lunghi periodi di tempo, impedendo l'avanzamento di altro lavoro. Se tutti gli
articoli vengono immessi con un singolo tasto Invio utilizzando un file secondario, la durata dei blocchi
per l'intero ordine è ridotta al minimo.
In generale, il numero e la durata dei blocchi devono essere ridotti al minimo in modo che diversi utenti
della stazione di lavoro possano accedere agli stessi dati senza lunghi periodi di attesa. È possibile
eseguire questa operazione non applicando i blocchi mentre l'utente immette i dati sul pannello. Alcune
applicazioni potrebbero richiedere che non più di un utente della stazione di lavoro acceda agli stessi
dati. Ad esempio, in un'applicazione di scrittura di importi con molti record di articolo aperti per cliente,
il tipico approccio consiste nel bloccare tutti i record e ritardarli finché un utente della stazione di lavoro
non ha completato la scrittura dell'importo per una specifica ricevuta.
Se l'utente della stazione di lavoro preme il tasto Invio varie volte per una transazione, è possibile
eseguire la transazione in diversi segmenti. Ad esempio:
v Il primo segmento è un'interrogazione in cui l'utente della stazione di lavoro richiede le informazioni.
v Il secondo segmento è una conferma dell'intento dell'utente della stazione di lavoro di completare
l'intera transazione.
v Il terzo segmento è il richiamo e l'aggiornamento dei record interessati.
Questo approccio consente di limitare il blocco di record a un singolo utilizzo di Invio.
Questo approccio che prevede prima l'esecuzione di un'interrogazione viene di norma utilizzato nelle
applicazioni in cui una decisione è determinata dalle informazioni visualizzate. Ad esempio, in
un'applicazione di prenotazioni di una compagnia aerea, un cliente può desiderare sapere quali sono gli
orari dei voli, le coincidenze e le disposizioni dei posti a sedere disponibili prima di decidere quale volo
prendere. Dopo che il cliente ha preso una decisione, la transazione viene immessa. Se la transazione ha
esito negativo (il volo risulta pieno), è possibile utilizzare la funzione di rollback e immettere una
76
IBM i: Database Controllo del commit
richiesta differente. Se i record sono bloccati dalla prima interrogazione finché non viene presa una
decisione, un altro addetto alle prenotazioni attenderà finché l'altra transazione non sarà stata completata.
Concetti correlati
“Controllo del commit per le applicazioni batch” a pagina 27
Le applicazioni batch possono richiedere o meno il controllo del commit. In alcuni casi, un'applicazione
batch può eseguire una singola funzione di lettura di un file di immissione e di aggiornamento di un file
master. Tuttavia, è possibile utilizzare il controllo del commit per questo tipo di applicazione se è
importante avviarla nuovamente dopo una fine anomala.
Commit soft
Il commit soft è una forma di controllo del commit che limita il numero di volte per cui il sistema scrive
delle voci di giornale associate a una transazione su disco.
Il commit soft può migliorare le prestazioni delle transazioni ma può causare la perdita di una o più
transazioni nel caso di un errore di sistema. Il controllo del commit classico su DB2 for i assicura la
durabilità delle transazioni; questo significa che, quando viene eseguito il commit di una transazione,
essa persiste sul sistema. Il commit soft non fornisce questa durabilità anche se assicura comunque
l'atomicità della transazione. In altre parole, il sistema garantisce un limite di commit, ma una o più
transazioni complete potrebbero andare perdute se si verifica un errore di sistema.
Per utilizzare il commit soft, sia per uno specifico lavoro o nell'ambito del sistema, specificare *NO nella
variabile di ambiente QIBM_TN_COMMIT_DURABLE. È possibile modificare questa variabile con il
comando ADDENVVAR (Aggiunta variabile di ambiente).
Ad esempio, per richiedere il commit soft da uno specifico lavoro, immettere il seguente comando dal
lavoro:
ADDENVVAR ENVVAR (QIBM_TN_COMMIT_DURABLE) VALUE (*NO)
Per richiedere il commit soft nell'ambito del sistema, immettere il seguente comando:
ADDENVVAR ENVVAR (QIBM_TN_COMMIT_DURABLE) VALUE (*NO) LEVEL (*SYS)
Nota: è necessario disporre dell'autorizzazione *JOBCTL per impostare questa variabile di ambiente a
livello del sistema.
Se la variabile di ambiente QIBM_TN_COMMIT_DURABLE non è stata aggiunta, o se la variabile di
ambiente è stata impostata su un valore diverso da *NO, il sistema non utilizza il commit soft; il sistema
utilizza invece il controllo del commit classico in modo tale che la durabilità delle transazioni sarà
assicurata.
È possibile controllare l'esistenza di questa nuova variabile di ambiente e il suo valore e il livello, se
esiste, utilizzando il comando WRKENVVAR (Gestione variabile di ambiente).
|
|
|
|
|
Il valore di questa variabile di ambiente viene memorizzato in cache internamente ogni volta che viene
avviato il controllo del commit. Se la variabile di ambiente viene modificata dopo tale punto, il valore
memorizzato nella cache deve essere aggiornato perché diventi effettivo. Qualsiasi chiamata dell'API di
richiamo di informazioni di commit QTNRCMTI aggiorna il valore memorizzato nella cache nel lavoro
chiamante.
Per alcune transazioni, il sistema operativo sceglie di ignorare la richiesta di commit soft ed esegue
invece un commit classico. Questo si verifica in alcuni ambienti complessi, dove sono richieste più
connessioni al database o dove sono in corso delle operazioni DDL. Il sistema operativo può determinare
quando è appropriato eseguire la richiesta e quando ha più senso eseguire un'operazione di commit
classica. Non è pertanto pericoloso richiedere un commit soft in ambienti di questo tipo.
Controllo del commit
77
Scenari ed esempi: controllo del commit
Questi scenari ed esempi mostrano in che modo una società configura il controllo del commit. In questa
raccolta di argomenti sono inclusi anche gli esempi di codice per i programmi che utilizzano il controllo
del commit.
Il seguente scenario mostra il modo in cui la JKL Toy Company implementa il controllo del commit per
tenere traccia delle transazioni sul suo database locale.
I seguenti esempi forniscono del codice di esempio per il controllo del commit. L'esercizio pratico è un
programma RPG che implementa il controllo del commit. Include un flusso logico che mostra cosa si
verifica a ogni passo del processo.
Scenario: controllo del commit
La JKL Toy Company utilizza il controllo del commit per proteggere i record di database per la
produzione e l'inventario. Questo scenario mostra in che modo la JKL Toy Company utilizza il controllo
del commit per trasferire una parte dal suo reparto di inventario al suo reparto di produzione.
Scenario: l'argomento della gestione del giornale include una descrizione dell'ambiente di rete della JKL
Toy Company. Lo scenario riportato di seguito mostra in che modo il controllo del commit agisce sul suo
sistema di produzione JKLPROD.
Questo scenario illustra i vantaggi offerti dall'utilizzo del controllo del commit in due esempi. Il primo
esempio mostra in che modo il programma di inventario della società, il programma A, può funzionare
senza il controllo del commit e i possibili problemi che possono verificarsi. Il secondo esempio mostra
come funziona il programma con il controllo del commit.
La JKL Toy Company utilizza un programma applicativo di inventario, il programma A, sul suo sistema
JKLPROD. Il programma A utilizza due record. Un record tiene traccia degli articoli conservati in
magazzino. Un altro record tiene traccia degli articoli spostati dal magazzino e utilizzati nella produzione.
Programma A senza controllo del commit
Supporre che il seguente programma applicativo non utilizza il controllo del commit. Il sistema blocca i
record letti per l'aggiornamento. I seguenti passi descrivono in che modo il programma applicativo tiene
traccia di un diodo dalla sua rimozione dal magazzino al suo trasferimento alla produzione:
v Il programma A blocca e richiama il record del magazzino. (Questa azione potrebbe richiedere un'attesa
se il record è bloccato da un altro programma).
v Il programma A blocca e richiama il record della produzione. (Anche questa azione potrebbe richiedere
un'attesa). Il programma A ora ha bloccato entrambi i record e nessun altro programma può
modificarli.
v Il programma A aggiorna il record del magazzino. Questo determina il rilascio del record in modo che
sia ora disponibile per essere letto per l'aggiornamento da qualsiasi altro programma.
v Il programma A aggiorna il record della produzione. Questo determina il rilascio del record in modo
che sia ora disponibile per essere letto per l'aggiornamento da qualsiasi altro programma.
Senza l'utilizzo del controllo del commit, è necessario risolvere un problema per fare in modo che questo
programma funzioni correttamente in tutte le circostanze. Ad esempio, si verifica un problema se il
programma A non aggiorna entrambi i record a causa di un errore di lavoro o di sistema. In questo caso,
i due file non sono congruenti; i diodi vengono rimossi dal record del magazzino ma non vengono
aggiunti al record della produzione. L'utilizzo del controllo del commit consente di assicurare che tutte le
modifiche coinvolte nella transazione siano completate o che i file vengano ripristinati al loro stato
originario se l'elaborazione della transazione viene interrotta.
78
IBM i: Database Controllo del commit
Programma A con il controllo del commit
Se viene utilizzato il controllo del commit, l'esempio precedente viene modificato nel seguente modo:
1. Il controllo del commit è avviato.
2. Il programma A blocca e richiama il record del magazzino. (Questa azione può richiedere un'attesa se
il record è bloccato da un altro programma).
3. Il programma A blocca e richiama il record della produzione. (Anche questa azione può richiedere
un'attesa). Il programma A ora ha bloccato entrambi i record e nessun altro programma può
modificarli.
4. Il programma A aggiorna il record del magazzino e il controllo del commit mantiene il blocco sul
record.
5. Il programma A aggiorna il record della produzione e il controllo del commit mantiene il blocco sul
record.
6. Il programma A esegue il commit della transazione. Le modifiche al record del magazzino e al record
della produzione vengono rese permanenti nei file. Le modifiche vengono registrate nel giornale, che
presume che saranno presenti su disco. Il controllo del commit rilascia i blocchi su entrambi i record. I
record sono ora disponibili per essere letti per l'aggiornamento da qualsiasi altro programma.
Poiché i blocchi su entrambi i record sono mantenuti dal controllo del commit finché non viene eseguito
il commit della transazione, non può verificarsi una situazione in cui un record viene aggiornato e l'altro
no. Se si verifica un errore di sistema o del passo di instradamento prima dell'esecuzione del commit
della transazione, il sistema elimina le (esegue il rollback delle) modifiche che sono state eseguite in
modo che i file siano aggiornati al punto in cui è stato eseguito il commit dell'ultima transazione.
Per ogni passo di instradamento in cui i file devono essere sotto il controllo del commit, si verificano i
passi mostrati nella seguente figura:
Controllo del commit
79
Le operazioni eseguite sotto il controllo del commit vengono registrate su giornale. La voce di giornale di
avvio del controllo del commit viene visualizzata dopo la prima voce di apertura file sotto il controllo del
commit. Questo è dovuto al fatto che la prima voce di apertura file determina quale giornale viene
utilizzato per il controllo del commit. La voce di giornale dalla prima operazione di apertura viene
quindi utilizzata per controllare le successive operazioni di apertura per assicurare che tutti i file stiano
utilizzando lo stesso giornale.
Quando si verifica un errore di sistema o di lavoro, le risorse sotto il controllo del commit vengono
aggiornate a un limite di commit. Se una transazione viene avviata ma non viene completata prima che
termini un passo di instradamento, tale transazione viene sottoposta a rollback dal sistema e non è
presente nel file dopo il termine del passo di instradamento. Se il sistema termina in modo anomalo
prima che una transazione venga completata, tale transazione viene sottoposta a rollback dal sistema e
non è presente nel file dopo un successivo IPL (initial program load) eseguito correttamente del LIC
(Licensed Internal Code - Microprogramma interno su licenza). Quando si verifica un rollback, delle voci
in ordine inverso vengono inserite nel giornale.
Si supponga, ad esempio, che la JKL Company abbia 100 diodi in stock. La produzione ne prende 20
dallo stock; il nuovo saldo è pertanto pari a 80. L'aggiornamento del database determina sia una voce di
giornale di immagine-precedente (100) sia una di immagine-successiva (80).
Si presuma che il sistema venga terminato in modo anomalo dopo la registrazione su giornale delle voci
ma prima di raggiungere il punto di commit o il punto di rollback. Dopo l'IPL, il sistema legge la voce di
80
IBM i: Database Controllo del commit
giornale e aggiorna il corrispondente record di database. Questo aggiornamento produce due voci di
giornale che invertono l'aggiornamento: la prima voce è l'immagine-precedente (80) e la seconda voce è
l'immagine-successiva (100).
Quando l'IPL viene completato correttamente dopo la fine anomala. il sistema elimina le (o esegue il
rollback delle) modifiche al database di cui non è stato eseguito il commit. Nell'esempio precedente, il
sistema elimina le modifiche dal record del magazzino perché un'operazione di commit non è presente
nel giornale per tale transazione. In questo caso, l'immagine-precedente del record di magazzino viene
inserita nel file. Il giornale contiene le modifiche sottoposte a rollback e un'indicazione che si è verificata
un'operazione di rollback.
Concetti correlati
Scenario: Journal management
Problema pratico per il controllo del commit
Questo esercizio pratico può essere di ausilio nel comprendere il controllo del commit e i suoi requisiti.
Queste operazioni presumono che l'utente abbia dimestichezza con il programma su licenza i5/OS, la
DFU (data file utility) e questa raccolta di argomenti.
Nota: utilizzando gli esempi di codice, si accettano i termini indicati nella sezione “Informazioni
sull'esonero di responsabilità e licenza del codice” a pagina 121.
Prima di iniziare questo problema, attenersi alla seguente procedura prerequisita:
1. Creare una libreria speciale per questo esercizio pratico. Nelle istruzioni, la libreria è denominata
CMTLIB. Sostituire alle ricorrenze rilevate di CTMLIB il nome della propria libreria.
2. Creare i file di origine e una descrizione del lavoro.
Per utilizzare il controllo del commit, attenersi alla seguente procedura:
1. Creare un file fisico denominato ITMP (file master degli articoli). La DDS (data description
specification) per questo file è la seguente:
10
20
30
40
A
A
A
A
R ITMR
ITEM
ONHAND
K ITEM
2
5
0
2. Creare un file fisico denominato TRNP (file di transazioni). Questo file viene utilizzato come un file
di registrazione delle transazioni. La DDS per questo file è la seguente:
10
20
30
40
A
A
A
A
R TRNR
QTY
ITEM
USER
5 0
2
10
3. Creare un file logico denominato TRNL (logica transazioni). Questo file viene utilizzato come ausilio
nel riavvio dell'applicazione. Il campo USER è la sequenza di tipo LIFO. La DDS per questo file è la
seguente:
10
20
30
A
A
R TRNR
K USER
LIFO
PFILE (TRNP)
4. Immettere il comando STRDFU e creare un'applicazione DFU denominata ITMU per il file ITMP.
Accettare i valori predefiniti offerti da DFU durante la definizione dell'applicazione.
5. Immettere il comando CHGDTA ITMU e immettere i seguenti record per il file ITMP:
Articolo
AA
BB
CC
Disponibile
450
375
4000
Controllo del commit
81
6. Terminare il programma utilizzando F3. Questa immissione fornisce dei dati sui quali opererà il
programma.
7. Creare il programma CL di elaborazione degli articoli (ITMPCSC) nel seguente modo:
PGM
DCL &USER *CHAR LEN(10)
RTVJOBA USER(&USER)
CALL ITMPCS PARM(&USER)
ENDPGM
Questo è il programma di controllo che richiama il programma ITMPCS. Richiama il nome utente e
lo trasmette al programma di elaborazione. Questa applicazione presume che vengano utilizzati dei
nomi utente univoci.
8. Creare un file video denominato ITMPCSD dalla DDS nel seguente modo.
Esistono due formati: il primo per il pannello di richiesta di base e il secondo per consentire
all'operatore di controllare l'ultima transazione immessa. Questo file video viene utilizzato dal
programma ITMPCS.
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..
1.00
2.00
3.00
4.00
5.00
6.00
7.00
8.00
9.00
10.00
11.00
12.00
13.00
14.00
15.00
16.00
17.00
18.00
19.00
20.00
21.00
22.00
23.00
24.00
25.00
26.00
27.00
28.00
29.00
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
R PROMPT
1
3
QTY
5
ITEM
2
0I
61
I
62
63
64
24
23
CA03(93 'End of program')
CA04(94 'Review last')
SETOFF(64 'No rcd to rvw')
2'INVENTORY TRANSACTIONS'
2'Quantity'
+1
ERRMSG('Invalid +
quantity' 61)
+5'ITEM'
+1
ERRMSG('Invalid +
Item number' 62)
ERRMSG('Rollback +
occurred' 63)
2'CF4 was pressed and +
there are no +
transactions for +
this user'
DSPATR(HI)
2'CF4 Review last +
transaction'
R REVW
1
QTY
5
ITEM
2
0
2'INVENTORY TRANSACTIONS'
+5'REVIEW LAST TRANSACTION'
3 2'Quantity'
+1EDTCDE(Z)
+5'Item'
+1
9. Studiare il flusso logico fornito in Flusso logico per l'esercizio pratico per il controllo del commit.
10. Immettere il comando STRSEU e immettere il sorgente nel seguente modo:
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..
1.00
2.00
3.00
4.00
5.00
6.00
7.00
8.00
9.00
10.00
11.00
12.00
82
FITMP
F*
FTRNP
F*
FTRNL
F
FITMPCSD
C* Enter
C
C
C
C
UF
E
O
E
K
DISK
KCOMIT
DISK
KCOMIT
E
K
DISK
TRNR
KRENAMETRNR1
CF E
WORKSTN
parameter with User name for -TRNP- file
*ENTRY
PLIST
PARM
USER
10
LOOP
TAG
EXFMTPROMPT
IF
IBM i: Database Controllo del commit
13.00
14.00
15.00
16.00
17.00
18.00
19.00
20.00
21.00
22.00
23.00
24.00
25.00
26.00
27.00
28.00
29.00
30.00
31.00
32.00
33.00
34.00
35.00
36.00
37.00
38.00
39.00
40.00
41.00
42.00
43.00
44.00
45.00
46.00
47.00
48.00
49.00
50.00
51.00
52.00
53.00
54.00
55.00
56.00
57.00
58.00
59.00
60.00
61 00
62.00
63 00
64.00
65.00
66.00
67.00
C* Check for CF3 for end of program
C
93
DO
End of Pgm
C
SETON
LR
C
RETRN
C
END
C* Check for CF4 for review last transaction
C
94
DO
Review last
C* Check for existence of a record for this user in -TRNL- file
C
USER
CHAINTRNR1
64
Not found
C
64
GOTO LOOP
C
EXFMTREVW
C
GOTO LOOP
C
END
C* Access Item record
C
ITEM
CHAINITMR
62
Not found
C* Handle -not found- Condition
C
62
GOTO LOOP
C* Does sufficient quantity exist
C
ONHAND
SUB QTY
TEST
50
61 Minus
C* Handle insufficient quantity
C
61
DO
C* Release Item record which was locked by the CHAIN for update
C
EXCPTRLSITM
C
GOTO LOOP
C
END
C* Change ONHAND and update the Item record
C
Z-ADDTEST
ONHAND
C
UPDATITMR
C* Test for Special Simulation Conditions
C
ITEM
IFEQ 'CC'
C*
Simulate program need for rollback
C
QTY
IFEQ 100
C
SETON
63
Simult Rlbck
C*
ROLBK
C
GOTO LOOP
C
END
C*
Simulate an abnormal program cancellation by Div by zero
C*
Operator Should respond -C- to inquiry message
C
QTY
IFEQ 101
C
Z-ADD0
ZERO
30
C
TESTZ
DIV ZERO
TESTZ
30
Msg occurs
C
END
C*
Simulate an abnormal job cancellation by DSPLY.
C*
Operator Should System Request to another job
C*
and cancel this one with OPTION(*IMMED)
C
QTY
IFEQ 102
C
'CC=102' DSPLY
Msg occurs
C
END
C
END
ITEM=CC
C* Write the -TRNP- file
C
WRITETRNR
C* Commit the update to -ITMP- and write to -TRNPC*
COMIT
C
GOTO LOOP
OITMR
E
RLSITM
11. Immettere il comando CRTRPGPGM per creare il programma ITMPCS dal sorgente immesso nel
passo precedente.
12. Immettere il comando CALL ITMPCSC, premere Invio e premere F4. Un messaggio indica che non ci
sono immissioni per questo operatore.
13. Immettere i seguenti dati per verificare se il programma funziona correttamente:
Quantità
3
4
Articolo
AA
BB
Controllo del commit
83
14. Premere F4. Il pannello di controllo mostra l'ultimo articolo BB immesso. Immettere i seguenti dati:
Quantità
5
9000
100
102
101
Articolo
FF (Viene generato un messaggio di numero articolo non
valido).
BB (Viene generato un messaggio di errore di quantità
insufficiente).
CC (Viene generato un messaggio di rollback).
CC (Deve essere eseguita l'operazione RPG DSPLY.
Premere il tasto Invio).
CC (il programma deve visualizzare un messaggio di
interrogazione che indica che si è verificata una
condizione di divisione per zero oppure un'indicazione
della condizione di terminazione, a seconda
dell'impostazione dell'attributo di lavoro INQMSGRPY. Se
viene visualizzato il messaggio di interrogazione,
immettere C per annullare il programma RPG e quindi C
per annullare il programma CL sull'interrogazione
successiva. Questo simula una condizione di errore
imprevista).
15. Immettere il comando di visualizzazione dati DSPDTA ITMP.
Verificare se i record AA e BB sono stati aggiornati correttamente. I valori devono essere AA = 447,
BB = 371 e CC = 3697. Notare che le operazioni di sottrazione di quantità da CC sono state eseguite
ma che i record delle transazioni non sono stati scritti.
16. Creare un ricevitore di giornale per il controllo del commit. Utilizzare il comando CRTJRNRCV
(Creazione ricevitore di giornale) per creare un ricevitore di giornale denominato RCVR1 nella
libreria CMRLIB. Specificare una soglia di almeno 5000KB. Una soglia più elevata è consigliata se il
sistema dispone di una quantità sufficiente di spazio per ottimizzare il tempo tra la generazione di
nuovi ricevitori di giornale al fine di ridurre al minimo l'impatto sulle prestazioni di giornali di
modifica troppo frequenti.
17. Creare un giornale per il controllo del commit. Utilizzare il comando CRTJRN (Creazione giornale)
per creare un giornale denominato JRNTEST nella libreria CMTLIB. Poiché questo giornale viene
utilizzato solo per il controllo del commit, specificare MNGRCV(*SYSTEM) DLTRCV(*YES). Per il
parametro JRNRCV, specificare il ricevitore di giornale creato al passo 16.
18. Utilizzare il comando STRJRNPF (Avvio file fisico su giornale) con i parametri FILE(CMTLIB/ITMP
CMTLIB/TRNP) JRN(CMTLIB/JRNTEST) per registrare su giornale i file da utilizzare per il
controllo del commit.
Il parametro IMAGES utilizza un valore predefinito di *AFTER, che indica che solo le modifiche
post-immagine dei record sono presenti nel giornale. I file ITMP e TRNP hanno ora avviato la
registrazione su giornale.
Di norma, si salvano i file dopo l'avvio della registrazione su giornale. Non è possibile applicare
delle modifiche registrate su giornale a un file ripristinato che non ha lo stesso JID delle voci di
giornale. Poiché questo esercizio pratico non richiede che si applichino le modifiche registrate su
giornale, è possibile tralasciare il salvataggio dei file registrati su giornale.
19. Immettere il comando CALL ITMPCSC e immettere le seguenti transazioni:
Quantità
5
6
Articolo
AA
BB
Terminare il programma premendo F3.
20. Immettere il comando Visualizzazione giornale: DSPJRN CMTLIB/JRNTEST.
Notare le voci presenti nel giornale. La stessa sequenza di voci (R UP = aggiornamento di ITMP
seguito da R PT = record aggiunto a TRNP) si verifica nel giornale così come è stata eseguita dal
84
IBM i: Database Controllo del commit
programma. Questo è dovuto al fatto che un file logico è definito sul file fisico TRNP e il sistema
sovrascrive il valore predefinito RPG. Se non esisteva alcun file logico, viene utilizzato il presupposto
di RPG di SEQONLY(*YES) e si presenta un blocco di voci PT perché i record vengono conservati nel
buffer RPG finché il blocco non è pieno.
21. Modificare il programma CL ITMPCSC nel seguente modo (le nuove istruzioni sono presentate con
un asterisco).
*
*
*
PGM
DCL &USER *CHAR LEN(10)
RTVJOBA USER(&USER)
STRCMTCTL LCKLVL(*CHG)
CALL ITMPCS PARM(&USER)
MONMSG MSGID(RPG9001) EXEC(ROLLBACK)
ENDCMTCTL
ENDPGM
Il comando STRCMTCTL configura l'ambiente di controllo del commit. La parola LCKLVL specifica
che i record letti per l'aggiornamento ma non aggiornati possono essere rilasciati durante la
transazione. Il comando MONMSG gestisce gli eventuali messaggi di escape RPG ed esegue un
ROLLBACK in caso di fine anomala del programma RPG. Il comando ENDCMTCTL termina
l'ambiente di controllo del commit.
22. Cancellare il programma ITMPCSC esistente e crearlo nuovamente.
23. Modificare il programma RPG per eliminare i simboli di commenti alle istruzioni 2.00, 4.00, 46.00 e
65.00. Il sorgente è ora pronto per l'utilizzo con il controllo del commit.
24. Cancellare il programma ITMPCS esistente e crearlo nuovamente. Il programma è ora pronto a
operare sotto il controllo del commit.
25. Immettere il comando CALL ITMPCSC e le seguenti transazioni:
Quantità
7
8
Articolo
AA
BB
26. Utilizzare la richiesta di sistema e richiedere l'opzione per visualizzare il lavoro corrente. Quando
viene visualizzato il pannello Visualizzazione lavoro, selezionare l'opzione 16 per richiedere la
visualizzazione dello stato del controllo del commit.
Notare i valori visualizzati. Ci devono essere due commit perché nel programma sono state eseguite
due istruzioni di commit.
27. Premere F9 per visualizzare un elenco dei file sotto il controllo del commit e la quantità di attività
per ciascun file.
28. Ritornare al programma e terminarlo premendo F3.
29. Immettere DSPJRN CMTLIB/JRNTEST e notare le voci per i file e le voci di giornale speciali per il
controllo del commit:
Voce
C BC
C SC
C CM
C EC
Significato
Si è verificato un comando STRCMTCTL.
Avvio del ciclo di commit. Questo si verifica quando la
prima operazione di database nella transazione causa
l'inserimento, l'aggiornamento o la cancellazione di un
record come parte del controllo del commit.
Si è verificata l'operazione di commit.
Si è verificato un comando ENDCMTCTL.
Le immagini-precedenti e le immagini-successive (tipi R UB e R UP) del controllo del commit si
verificano automaticamente anche se in origine era stato richiesto IMAGES(*AFTER) per il giornale.
30. Immettere il comando CALL ITMPCSC e le seguenti transazioni:
Controllo del commit
85
Quantità
12
100
Articolo
AA
CC (Questa è la condizione per simulare l'esigenza per
un'applicazione di utilizzare il rollback. Il record CC nel
file ITMP, che era stato aggiornato dall'istruzione RPG
40.00, viene sottoposto a rollback).
31. Premere F4 per determinare l'ultima transazione immessa.
L'ultima transazione di cui è stato eseguito il commit è la voce per l'elemento AA.
32. Utilizzare la richiesta di sistema e richiedere l'opzione per visualizzare il lavoro corrente. Quando
viene visualizzato il pannello Visualizzazione lavoro, richiedere la visualizzazione dello stato del
controllo del commit.
Notare i valori visualizzati e come sono stati modificati dal rollback.
33. Ritornare al programma.
34. Ritornare al pannello di richiesta di base e terminare il programma premendo F3.
35. Immettere il comando DSPJRN CMTLIB/JRNTEST.
Notare le voci aggiuntive presenti nel giornale per l'utilizzo della voce di rollback (voce C RB).
Quando viene eseguito il rollback del record ITMP, nel giornale vengono inserite tre voci. Questo è
dovuto al fatto che qualsiasi modifica al file di database sotto il controllo del commit produce una
voce prima (R BR) e dopo (R UR).
36. Visualizzare le voci con il codice giornale R e questi tipi di voce: UB, UP, BR e UR. Utilizzare
l'opzione 5 per visualizzare le voci complete. Poiché il campo Quantità è in decimale compatto,
utilizzare F11 per richiedere una visualizzazione esadecimale. Notare le seguenti condizioni:
v Il valore di disponibilità del record ITMP nel record UB
v Come il valore di disponibilità viene ridotto dal record UP
v Come il record BR sia uguale al record UP
v Come il record UR restituisce il valore così come è visualizzato in origine per il record UB
L'ultima voce è la voce RB per la fine del rollback.
37. Immettere il comando CALL ITMPCSC, premere Invio e premere F4. Notare l'ultima transazione
immessa.
38. Immettere le seguenti transazioni:
Quantità
13
101
Articolo
AA
CC (Questa è la condizione per simulare una condizione
di errore imprevista che causa la terminazione del
programma. La simulazione si verifica dividendo un
campo per 0. Il programma visualizzerà un messaggio di
interrogazione o un'indicazione della condizione di
terminazione, a seconda dell'impostazione dell'attributo
di lavoro INQMSGRPY. Se viene visualizzato il messaggio
di interrogazione, immettere C per terminare il
programma. Poiché il programma CL è stato modificato
per monitorare il verificarsi di errori di programma RPG,
la seconda interrogazione che si verificava non si
verifica).
39. Immettere il comando DSPJRN CMTLIB/JRNTEST.
Si è verificato lo stesso tipo di gestione del rollback, ma questa volta il rollback è stato causato dal
parametro EXEC del comando MONMSG nel programma CL invece del programma RPG.
Visualizzare le due voci RB per appurare quale programma li ha causati.
40. Immettere il comando WRKJOB e annotare il nome lavoro completo da utilizzare successivamente.
86
IBM i: Database Controllo del commit
41. Immettere il comando CALL ITMPCSC e immettere la seguente transazione:
Quantità
14
102
Articolo
AA
CC (L'operazione RPG DSPLY deve verificarsi sulla coda
messaggi esterna. Utilizzare il tasto di richiesta sistema e
selezionare l'opzione 1 nel menu di richiesta sistema per
eseguire il trasferimento a un lavoro secondario).
42. Collegarsi al secondo lavoro e ristabilire l'ambiente.
43. Immettere il comando ENDJOB e specificare il nome lavoro completo identificato precedentemente e
l'opzione OPTION(*IMMED). Questo simula una fine anomala o una terminazione di sistema.
44. Attendere circa 30 secondi, immettere il comando CALL ITMPCSC e premere F4.
Notare l'ultima transazione sottoposta a commit. Deve essere la voce AA immessa precedentemente.
45. Ritornare al pannello di richiesta di base e terminare il programma premendo F3.
46. Immettere il comando DSPJRN CMTLIB/JRNTEST.
Si è verificato lo stesso tipo di gestione del rollback, ma questa volta il rollback è stato causato dal
sistema invece che da uno dei programmi. La voce RB è stata scritta dal programma QWTPITPP, che
è il programma di fine anomala della gestione lavoro.
A questo punto, sono state utilizzate le funzioni di base del controllo del commit. È possibile procedere
con il controllo del commit sulle proprie applicazioni oppure provare qualcuna delle altri funzioni, tipo:
v L'utilizzo di un oggetto di notifica
v Il blocco di record di sola lettura con LCKLVL(*ALL)
v Il blocco di più record nello stesso file con LCKLVL(*ALL)
Flusso logico per l'esercizio pratico
Il flusso logico può essere di ausilio nel comprendere ulteriormente questo programma pratico per il
controllo del commit. La seguente figura mostra il flusso dell'esercizio pratico per il controllo del commit.
Consultare “Passi associati al flusso logico per il programma pratico” a pagina 89 per informazioni
dettagliate su ciascuna delle operazioni illustrate nella figura.
Controllo del commit
87
88
IBM i: Database Controllo del commit
Passi associati al flusso logico per il programma pratico
Questi passi sono associati al flusso logico per l'esercizio pratico.
1. Richiamare il nome utente trasmesso come un parametro. Viene utilizzato per scrivere nel file TRNP
e anche per richiamare l'ultima transazione immessa da ciascun operatore . Questa applicazione
presume dei nomi utente univoci per gli operatori.
2. Richiedere il pannello di base utilizzando il nome formato PROMPT.
3. Se viene premuto F3, avviare una funzione di terminazione del programma.
4. Se viene premuto F4, avviare una routine per accedere all'ultima transazione immessa dall'operatore.
5. Leggere il record di articolo utilizzando il campo ITEM. Poiché il file è un file di aggiornamento,
questa richiesta blocca il record.
6. Controllare l'eventuale presenza di una condizione di non trovato nel file ITMP.
7. Se non esiste alcun record ITMP, impostare come attivo un indicatore 62 per causare il messaggio di
errore e ritornare al passo 2.
8. Sottrarre la quantità richiesta (QTY) dal saldo disponibile (ONHAND) in un'altra area di lavoro.
9. Verificare se è disponibile una quantità sufficiente per soddisfare la richiesta.
10. Se è disponibile una quantità insufficiente, rilasciare il blocco sul record nel file ITMP. Questo passo
è necessario perché la quantità non è sufficiente.
11. Impostare come attivo l'indicatore 61 per visualizzare un messaggio di errore di quantità insufficiente
e ritornare al passo 2.
12. Modificare il campo ONHAND per il nuovo saldo e aggiornare il record ITMR.
13. Controllare la presenza di una voce speciale nel campo ITEM che è possibile utilizzare per simulare
le condizioni in cui è richiesto il ROLLBACK.
14. Controllare la presenza di QTY=100. Emettere un'operazione ROLLBACK. Questo simula una
condizione in cui il programma rileva che è necessario eseguire il rollback.
15. Controllare la presenza di QTY=101. Causare un'eccezione nel programma che produrrà un
messaggio di interrogazione. Utilizzare la divisione per zero per questa funzione. L'operatore deve
immettere C per annullare il programma, a meno che l'opzione INQMSGRPH della descrizione del
lavoro non fornisca una risposta automatica. Questo simula una condizione in cui si è verificato un
errore imprevisto e l'operatore annulla il programma.
16. Controllare la presenza di QTY=102. Emettere una visualizzazione con l'operazione di interrogazione.
Questo arresta il programma a questo passo e consente l'utilizzo del tasto di richiesta sistema per
ottenere un lavoro differente. Annullare il lavoro di aggiornamento. Questo simula una condizione in
cui si è verificata una fine anomala di lavoro o di sistema durante un limite di commit.
17. Scrivere il record di transazione in TRNP.
18. Eseguire il commit dei record per la transazione e ritornare al passo 2.
19. Leggere il primo record nel percorso di accesso per il file TRNL, utilizzando USER come chiave.
Poiché questo file è in sequenza LIFO, questo sarà l'ultimo record di transazione immesso da questo
utente.
20. Controllare la presenza di una condizione di record non trovato nel file TRNL che si verifica se il file
non contiene voci per questo utente.
21. Se non ci sono record per questo utente, impostare come attivo l'indicatore 64 per causare un
messaggio di errore e ritornare al passo 2.
22. Visualizzare l'ultima transazione immessa per questo utente. Queste informazioni possono essere
utilizzate se l'operatore dimentica cosa era stato immesso precedentemente o quando viene riavviata
la transazione. Quando l'operatore risponde, ritornare al passo 2.
23. Eseguire le funzioni programma desiderate.
Controllo del commit
89
Esempio: utilizzo di un file di registrazione delle transazioni per
avviare un'applicazione
Questo esempio fornisce il codice di esempio e le istruzioni su come utilizzare un file di registrazione
delle transazioni per avviare un'applicazione dopo una fine anomala.
Nota: utilizzando gli esempi di codice, si accettano i termini indicati nella sezione “Informazioni
sull'esonero di responsabilità e licenza del codice” a pagina 121.
Un file di registrazione delle transazioni viene utilizzato per riavviare un'applicazione dopo un errore di
sistema o di lavoro quando non viene utilizzato un oggetto di notifica. Un file di registrazione delle
transazioni viene spesso utilizzato nelle applicazioni interattive per riepilogare gli effetti di una
transazione.
Ad esempio, in un'applicazione di immissione di ordini, un record viene di norma scritto in un file di
registrazione delle transazioni per ogni articolo ordinato. Il record contiene l'articolo ordinato, la quantità
e il prezzo. Nell'applicazione di conti debitore, viene scritto un record in un file di registrazione delle
transazioni per ogni numero di conto che deve ricevere un addebito. Questo record di norma contiene
informazioni quali il numero di conto, l'importo addebitato e il fornitore.
In molte delle applicazioni dove già esiste un file di registrazione delle transazioni, un utente della
stazione di lavoro può richiedere informazioni sull'ultima transazione immessa. Aggiungendo il controllo
del commit alle applicazioni in cui già esiste un file di registrazione delle transazioni, è possibile:
v Assicurare che i file di database siano aggiornati a un limite di commit.
v Semplificare il riavvio della transazione.
È necessario poter identificare in modo univoco l'utente della stazione di lavoro se si utilizza un file di
registrazione delle transazioni per il riavvio delle applicazioni sotto il controllo del commit. Se vengono
utilizzati dei nomi di profilo utente univoci sul sistema, il nome profilo può essere inserito in un campo
nel record della registrazione della transazione. Questo campo può essere utilizzato come chiave per il
file.
I seguenti esempi presumono che venga utilizzato un file di inventario dell'ordine per eseguire le
transazioni e che già esista un file di registrazione delle transazioni. Il programma esegue le seguenti
attività:
1. Richiedere all'utente della stazione di lavoro una quantità e un numero di articolo.
2. Aggiornare la quantità nel file master di produzione (PRDMSTP).
3. Scrivere un record nel file di registrazione delle transazioni (ISSLOGL).
Se la quantità di inventario disponibile è insufficiente, il programma rifiuta la transazione. L'utente della
stazione di lavoro può chiedere al programma dove è stata interrotta l'immissione di dati perché il
numero dell'articolo, la descrizione, la quantità, il nome utente e la data vengono scritti nel file di
registrazione delle transazioni.
DDS per il file fisico PRDMSTP
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7
1.00
2.00
3.00
4.00
5.00
6.00
90
A
A
A
A
A
A
R PRDMSTR
PRODCT
DESCRP
ONHAND
K PRODCT
IBM i: Database Controllo del commit
3
20
5 0
TEXT('Master record')
COLHDG('Product' 'Number')
COLHDG('Description')
COLHDG('On Hand' 'Amount')
EDTCDE(Z)
DDS per il file fisico ISSLOGP utilizzato da ISSLOGP
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7
1.00
2.00
3.00
4.00
5.00
6.00
7.00
8.00
A
A
A
A
A
A
A
A
R ISSLOGR
PRODCT
DESCRP
QTY
TEXT('Product log record')
COLHDG('Product' 'Number')
COLHDG('Description')
COLHDG('Quantity')
EDTCDE(Z)
COLHDG('User' 'Name')
EDTCDE(Y)
COLHDG('Date')
3
20
3 0
USER
DATE
10
6
0
DDS per il file logico ISSLOGL
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7
1.00
2.00
3.00
A
A
A
LIFO
PFILE(ISSLOGP)
R ISSLOGR
K USER
DDS per il file video PRDISSD utilizzato nel programma
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..
1.00
2.00
3.00
4.00
5.00
6.00
7.00
8.00
9.00
10.00
11.00
12.00
13.00
14.00
15.00
16.00
17.00
18.00
19.00
20.00
21.00
22.00
23.00
24.00
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
REF(ISSLOGP)
R PROMPT
1
3
QTY
R
I
PRODCT
R
I
62
61
55
15
24
CA03(98 'End of program')
CA02(97 'Where am I')
20'ISSUES PROCESSING'
2'Quantity'
+1
ERRMSG('Not enough +
Qty' 62)
+6'Product'
+1
ERRMSG('No Product +
record found' 62)
2'No Previous record exists'
2'CF2 Last transaction'
R RESTART
PRODCT
R
DESCRP
R
QTY
R
1 20'LAST TRANSACTION +
INFORMATION'
5 2'Product'
+1
7 2'Description'
+1
9 2'Qty'
+1REFFLD(QTY)
Questo processo è illustrato nel Flusso di programma.
Controllo del commit
91
92
IBM i: Database Controllo del commit
Il codice operazione RPG COMMIT viene specificato dopo l'aggiornamento del file PRDMSTP e la
scrittura del record nel file di registrazione delle transazioni. Poiché ogni richiesta all'operatore
rappresenta un limite per una nuova transazione, la transazione viene considerata come una transazione
a singolo Invio.
Il nome utente viene trasmesso al programma quando viene richiamato. Il percorso di accesso per il file
di registrazione delle transazioni è definito in sequenza LIFO (last-in-first-out) in modo che il programma
possa accedere facilmente all'ultimo record immesso.
L'utente della stazione di lavoro può riavviare il programma dopo un errore di sistema o di lavoro
utilizzando la stessa funzione che ha identificato il punto in cui è stata arrestata l'immissione di dati. Non
è necessario aggiungere nuovo codice al programma. Se si sta attualmente utilizzando un file di
registrazione delle transazioni ma non lo si sta utilizzando per appurare il punto in cui ci si trova,
aggiungere il nome utente al file di registrazione delle transazioni (presumendo che i nomi utente siano
univoci) e utilizzare questo approccio nel programma.
Il seguente esempio mostra il programma RPG utilizzato. Le istruzioni richieste per il controllo del
commit sono contrassegnate con delle frecce (==>).
Programma RPG
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... .. 7 ..
=>1.00
FPRDMSTP UP E
K
DISK
KCOMIT
=>2.00
FISSLOGL IF E
K
DISK
KCOMIT
3.00
PRDISSD CP E
WORKSTN
4.00
*ENTRY
PLIST
5.00
PARM
USER
10
6.00
C*
7.00
C* Initialize fields used in Trans Log Rcd
8.00
C*
9.00
C
MOVE UDATE
DATE
10.00
C*
11.00
C* Basic processing loop
12.00
C*
13.00
C
LOOP
TAG
14.00
C
EXFMTPROMPT
15.00
C
98
GOTO END
End of pgm
16.00
C
97
DO
Where am I
17.00
C
EXSR WHERE
18.00
C
GOTO LOOP
19.00
C
END
20.00
C
PRODCT
CHAINPRDMSTR
61
Not found
21.00
C
61
GOTO LOOP
22.00
C
ONHAND
SUB QTY
TEST
50
62
Less than
23.00
C
62
DO
Not enough
24.00
C
EXCPTRLSMST
Release lock
25.00
C
GOTO LOOP
26.00
C
END
27.00
C*
28.00
C* Update master record and output the Transaction Log Record
29.00
C*
30.00
C
Z-ADDTEST
ONHAND
31.00
C
UPDATPRDMSTR
32.00
C
WRITEISSLOGR
=>33.00
C
COMIT
34.00
C
GOTO LOOP
35.00
C*
36.00
C* End of program processing
37.00
C*
38.00
C
END
TAG
39.00
C
SETON
LR
Controllo del commit
93
40.00
41.00
42.00
43.00
44.00
45.00
46.00
47.00
C*
C* WHERE subroutine for "Where am I" requests
C*
C
WHERE
BEGSR
C
USER
CHAINISSLOGL
C N55
EXFMTRESTART
C
ENDSR
OPRDMSTR E
RLSMST
55
Not found
Programma CL utilizzato per richiamare il programma RPG PRDISS
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..
1.00
2.00
3.00
4.00
5.00
6.00
7.00
8.00
PGM
DCL
STRCMTCTL
RTVJOBA
CALL
MONMSG
ENDCMTCTL
ENDPGM
&USER *CHAR LEN(10)
LCKLVL(*CHG)
USER(&USER)
PRDISS PARM(&USER)
MSGID(RPG900l) EXEC(ROLLBACK)
Per utilizzare il controllo del commit in questo programma, viene normalmente specificato un livello di
blocco *CHG. Il record viene bloccato dalla modifica finché non viene eseguita un'operazione di commit.
Notare che se è presente una quantità insufficiente di inventario, il record viene rilasciato in modo
esplicito. (Se il record non viene rilasciato in modo esplicito nel programma, viene rilasciato quando il
successivo record viene letto per l'aggiornamento dal file).
In questo esempio, l'utilizzo del livello di blocco *ALL non comporta alcun vantaggio aggiuntivo. Se
viene utilizzato *ALL, è necessario utilizzare un'operazione di rollback o di commit per rilasciare il record
quando la quantità disponibile è risultata insufficiente.
Il codice precedente è un programma CL che richiama il programma RPG PRDISS. Notare l'utilizzo di
comandi STRCMTCTL/ENDCMTCTL. Il nome utente univoco viene richiamato (comando RTVJOBA) e
trasmesso al programma. L'utilizzo del comando MONMSG per causare un rollback è descritto
nell'Esempio: utilizzo di un programma di elaborazione standard per avviare un'applicazione.
Concetti correlati
“Esempio: utilizzo di un programma di elaborazione standard per avviare un'applicazione” a pagina 101
Un programma di elaborazione standard è un modo per riavviare l'applicazione utilizzando un singolo
file di database come oggetto di notifica per tutte le applicazioni. Questo approccio presume che i nomi
di profilo utente siano univoci in base all'utente per tutte le applicazioni che utilizzano il programma
standard.
“Esempio: oggetto di notifica univoco per ciascun programma” a pagina 96
L'utilizzo di un singolo oggetto di notifica univoco per ciascun lavoro consente l'utilizzo di
un'identificazione di commit descritta esternamente anche se potrebbero esserci più utenti dello stesso
programma.
Esempio: utilizzo di un oggetto di notifica per avviare un'applicazione
Quando viene avviato dopo una fine anomala, un programma può cercare una voce nell'oggetto di
notifica. Se la voce esiste, il programma può riavviare una transazione. Dopo che la transazione è stata
avviata nuovamente, l'oggetto di notifica viene cancellato dal programma per evitare che avvii la stessa
transazione un'ennesima volta.
È possibile utilizzare un oggetto di notifica nei seguenti modi:
v Se l'identificazione di commit viene inserita in un file di database, eseguire la query di questo file per
determinare dove riavviare ciascun lavoro di applicazione o di stazione di lavoro.
94
IBM i: Database Controllo del commit
v Se l'identificazione di commit viene inserita in una coda messaggi per una specifica stazione di lavoro,
un messaggio può essere inviato agli utenti della stazione di lavoro quando si collegano per informarli
dell'ultima transazione di cui è stato eseguito il commit.
v Se l'identificazione di commit viene inserita in un file di database che ha un nome utente o una chiave,
il programma può leggere questo file quando viene avviato. Se esiste un record nel file, riavviare il
programma. Il programma può inviare un messaggio all'utente della stazione di lavoro che identifica
l'ultima transazione di cui è stato eseguito il commit. Eventuali ripristini vengono eseguiti dal
programma. Se nel file di database esisteva un record, il programma cancella tale record alla fine del
programma.
v Per un'applicazione batch, l'identificazione di commit può essere inserita in un'area di dati che contiene
i totali, le impostazioni di commutazione e altre informazioni sullo stato che occorrono per riavviare
l'applicazione. Quando viene avviata, l'applicazione accede all'area di dati e verifica i valori in essa
memorizzati. Se l'applicazione termina normalmente, l'area di dati è configurata per la successiva
esecuzione.
v Per un'applicazione batch, l'identificazione di commit può essere inviata a una coda messaggi. Un
programma eseguito quando viene avviata l'applicazione può richiamare i messaggi dalla coda e
riavviare i programmi.
È possibile utilizzare diverse tecniche per riavviare le applicazioni, a seconda delle esigenze delle
applicazioni. Quando si sceglie la tecnica, considerare le seguenti informazioni:
v Quando ci sono più utenti di un programma contemporaneamente, non è possibile utilizzare una
singola area di dati come oggetto di notifica perché, dopo una fine di sistema anomala, le
identificazioni di commit per ogni utente si sovrapporranno nell'area di dati.
v La progettazione per eliminare le informazioni nell'oggetto di notifica deve gestire la situazione in cui
si verifica un errore immediatamente dopo l'utilizzo delle informazioni:
– Se le informazioni vengono cancellate immediatamente, esse non esistono se si verifica un altro
errore prima dell'elaborazione della transazione interrotta.
– Le informazioni nell'oggetto di notifica non devono essere cancellate fino alla corretta elaborazione
della transazione interrotta. In questo caso, esisterà più di una voce nell'oggetto di notifica se si
tratta di un file di database o di una coda messaggi.
– Il programma deve accedere all'ultimo record, se c'è più di una voce.
v Un oggetto di notifica non può essere utilizzato per fornire all'utente della stazione di lavoro l'ultima
transazione di cui è stato eseguito il commit perché l'oggetto di notifica viene aggiornato solo se si
verifica un errore di sistema o di lavoro o se esistono delle modifiche di cui non è stato eseguito il
commit quando un lavoro viene terminato in modo normale.
v Se per l'utente della stazione di lavoro vengono visualizzate delle informazioni, esse devono essere
significative. Questo potrebbe richiedere che il programma traduca dei codici conservati nell'oggetto di
notifica in informazioni che aiuteranno l'utente ad eseguire il riavvio.
v Le informazioni per il riavvio devono essere visualizzate se l'utente della stazione di lavoro ne ha
bisogno. È necessaria della logica aggiuntiva nel programma per evitare che le informazioni vengano
nuovamente visualizzate quando non sono più significative.
v Un singolo oggetto di notifica e un programma di elaborazione standard possono fornire una funzione
di riavvio se l'oggetto di notifica è un file di database. Questo programma di elaborazione standard
viene richiamato dai programmi che richiedono la capacità di eseguire il riavvio per ridurre al minimo
le modifiche a ogni singolo programma.
Controllo del commit
95
Concetti correlati
“Oggetto di notifica del commit” a pagina 53
Un oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioni
che identificano l'ultima transazione eseguita correttamente completata per una specifica definizione di
commit se tale definizione di commit non è stata terminata normalmente.
Esempio: oggetto di notifica univoco per ciascun programma
L'utilizzo di un singolo oggetto di notifica univoco per ciascun lavoro consente l'utilizzo di
un'identificazione di commit descritta esternamente anche se potrebbero esserci più utenti dello stesso
programma.
Nei seguenti esempi, un file di database viene utilizzato come un oggetto di notifica e viene utilizzato
solo da questo programma.
Il programma ha due file di database (PRDMSTP e PRDLOCP) che devono essere aggiornati per le
ricevute da inventariare. Il file video utilizzato dal programma è denominato PRDRCTD. Un file di
database, PRDRCTP, viene utilizzato come oggetto di notifica. Questo oggetto di notifica è definito per il
programma come un file e viene utilizzato anche come definizione di una struttura di dati per la
funzione di notifica.
Nota: utilizzando gli esempi di codice, si accettano i termini indicati nella sezione “Informazioni
sull'esonero di responsabilità e licenza del codice” a pagina 121.
DDS per il file fisico PRDLOCP
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7
1.00
2.00
3.00
4.00
5.00
6.00
7.00
A
A
A
A
A
A
A
R PRDLOCR
PRODCT
LOCATN
LOCAMT
3
6
5
0
TEXT('Location record')
COLHDG('Product' 'Number')
COLHDG('Location')
COLHDG('Location' 'Amount')
EDTCDE(Z)
K PRODCT
K LOCATN
DDS per il file video PRDRCTD
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..
1.00
2.00
3.00
4.00
5.00
6.00
7.00
8.00
9.00
10.00
11.00
12.00
13.00
14.00
15.00
16.00
17.00
18.00
19.00
20.00
21.00
22.00
23.00
24.00
96
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
REF(PRDMSTP)
R PROMPT
QTY
3
PRODCT
R
LOCATN
R
61
62
71
IBM i: Database Controllo del commit
CA03(98 'End of program')
SETOFF(71 'RESTART')
1 20'PRODUCT RECEIPTS'
3
2'Quantity'
OI
+1
+6'Product'
I
+1
ERRMSG('No record +
found in the +
master file' 62)
+6'Location'
I
+1REFFLD(LOCATN PRDLOCP)
ERRMSG('No record +
found in the +
location file' 62)
9
2'Last Transaction'
+6'This is restart +
information'
DSPATR(HI BL)
12
2'Quantity'
12 12'Product'
12 23'Location'
25.00
26.00
27.00
28.00
29.00
30.00
A
A
A
A
A
A
LSTPRD
LSTLOC
LSTQTY
R
R
R
LSTDSC
R
12 35'Description'
14 15REFFLD(PRODCT)
14 26REFFLD(LOCATN *SRC)
14
5REFFLD(QTY *SRC)
EDTCDE(Z)
14 35REFFLD(DESCRP)
DDS per l'oggetto di notifica e la struttura di dati descritta esternamente (PRDRCTP)
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..
1.00
2.00
3.00
4.00
5.00
6.00
7.00
8.00
9.00
A
A
A
A
A
A
A
A
A
LIFO
REF(PRDMSTP)
R PRDRCTR
USER
PRODCT
DESCRP
QTY
LOCATN
K USER
10
R
R
3
R
0
REFFLD(LOCATN PRDLOCP)
Il programma elabora l'oggetto di notifica nel seguente modo:
v Inizialmente, il programma elabora casualmente l'oggetto di notifica e visualizza un record se esiste per
la chiave specifica:
– Se esistono più record, viene utilizzato l'ultimo record per questa chiave perché il file PRDRCTP è in
sequenza LIFO.
– Se non esiste alcun record, una transazione non è stata interrotta e quindi non è necessario
riavviarla.
– Se il programma ha esito negativo prima della prima operazione di commit eseguita correttamente,
non valuta che è richiesto il riavvio.
v La routine per cancellare i dati dall'oggetto di notifica si trova alla fine del programma:
– Se si sono verificati più malfunzionamenti, la routine può gestire la cancellazione di più record
nell'oggetto di notifica.
– Anche se il sistema inserisce l'identificazione di commit in un file di database, l'identificazione di
commit deve essere specificata come una variabile nel programma RPG.
– Poiché RPG consente la descrizione esterna di una struttura di dati, una struttura di dati è un modo
pratico per specificare l'identificazione di commit. In questo esempio, la struttura di dati utilizza la
stessa descrizione esterna utilizzata dal file di database come oggetto di notifica.
L'elaborazione per questo programma richiede all'utente un numero di prodotto, un'ubicazione e una
quantità:
v Devono essere aggiornati due file:
– Il file master del prodotto (PRDMSTP)
– Il file di ubicazione del prodotto (PRDLOCP)
v In ciascun file deve esistere un record prima che l'uno o l'altro venga aggiornato.
v Il programma sposta i campi di immissione ai corrispondenti ultimi campi dopo la corretta immissione
di ciascuna transazione. Questi ultimi campi vengono visualizzati all'operatore su ciascuna richiesta
come feedback dell'immissione più recente.
v Se le informazioni per il riavvio esistono, vengono spostate a questi ultimi campi e sul pannello viene
presentato un messaggio speciale.
Questo processo è illustrato nella seguente figura. Il nome utente viene trasmesso al programma per
fornire un record univoco nell'oggetto di notifica.
Controllo del commit
97
98
IBM i: Database Controllo del commit
Il seguente esempio è relativo al codice sorgente RPG. L'oggetto di notifica (file PRDRCTP) viene
utilizzato come un file normale all'inizio e alla fine del programma e viene specificato anche come
oggetto di notifica nel CL (comando STRCMTCTL) prima di richiamare il programma.
Sorgente RPG
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..
1.00
2.00
3.00
4.00
5.00
6.00
7.00
8.00
9.00
10.00
11.00
12.00
13.00
14.00
15.00
16.00
17.00
18.00
19.00
20.00
21.00
22.00
23.00
24.00
25.00
26.00
27.00
28.00
29.00
30.00
31.00
32.00
33.00
34.00
35.00
36.00
37.00
38.00
39.00
40.00
41.00
42.00
43.00
44.00
45.00
46.00
47.00
48.00
49.00
50.00
51.00
52.00
53.00
54.00
55.00
57.00
FPRDMSTP UF E
K
DISK
KCOMIT
FPRDLOCP UF E
K
DISK
KCOMIT
FPRDRCTD CF E
WORKSTN
F*
F* The following file is the specific notify object for this pgm.
F*
It is accessed only in a restart situation and at the
F*
end of the program to delete any records. The records
F*
are written to the notify object by Commitment Control.
F*
FPRDRCTP UF E
K
DISK
ICMTID
E DSPRDRCTP
C
*ENTRY
PLIST
C
PARM
USER10 10
C
MOVE USER10
USER
C*
C* Check for restart information - get last rcd per user
C*
PRDRCTP file access path is in LIFO sequence
C*
C
USER
CHAINPRDRCTR
20
Not found
C N20
DO
Restart
C
EXSR MOVLST
Move to last
C
SETON
71
Restart
C
END
C*
C* Basic processing loop
C*
C
L00P
TAG
C
EXFMTPROMPT
C
98
GOTO END
End of pgm
C
PRODCT
CHAINPRDMSTR
61
Not found
C
61
GOTO L00P
C
KEY
KLIST
C
KFLD
PRODCT
C
KFLD
LOCATN
C
KEY
CHAINPRDLOCR
62
Not found
C
62
DO
C
EXCPTRLSMST
Release lck
C
GOTO L00P
C
END
C
ADD QTY
ONHAND
Add
C
ADD QTY
LOCAMT
C
UPDATPRDMSTR
Update
C
UPDATPRDLOCR
Update
C*
C* Commit and move to previous fields
C*
C
CMTID
COMIT
C
EXSR MOVLST
Move to last
C
GOTO L00P
C*
C* End of program processing
C*
C
END
TAG
C
SETON
LR
C*56.00
C* Delete any records in the notify object
C*
Controllo del commit
99
58.00
59.00
60.00
61.00
62.00
63.00
64.00
65.00
66.00
67.00
68.00
69.00
70.00
71.00
72.00
73.00
C
DLTLP
TAG
C
USER
CHAINPRDRCTR
20
C N20
DO
C
DELETPRDRCTR
C
GOTO DLTLP
C
END
C*
C* Move to -Last Used- fields for operator feedback
C*
C
MOVLST
BEGSR
C
MOVE PRODCT
LSTPRD
C
MOVE LOCATN
LSTLOC
C
MOVE QTY
LSTQTY
C
MOVE DESCRP
LSTDSC
C
ENDSR
OPRDMSTR E
RLSMST
Not found
Delete
Concetti correlati
“Esempio: utilizzo di un file di registrazione delle transazioni per avviare un'applicazione” a pagina 90
Questo esempio fornisce il codice di esempio e le istruzioni su come utilizzare un file di registrazione
delle transazioni per avviare un'applicazione dopo una fine anomala.
“Oggetto di notifica del commit” a pagina 53
Un oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioni
che identificano l'ultima transazione eseguita correttamente completata per una specifica definizione di
commit se tale definizione di commit non è stata terminata normalmente.
“Esempio: oggetto di notifica singolo per tutti i programmi”
L'utilizzo di un singolo oggetto di notifica per tutti i programmi è vantaggioso. Questo è dovuto al fatto
che tutte le informazioni richieste per il riavvio si trovano nello stesso oggetto ed è possibile utilizzare un
approccio standard all'oggetto di notifica in tutti i programmi.
Esempio: oggetto di notifica singolo per tutti i programmi
L'utilizzo di un singolo oggetto di notifica per tutti i programmi è vantaggioso. Questo è dovuto al fatto
che tutte le informazioni richieste per il riavvio si trovano nello stesso oggetto ed è possibile utilizzare un
approccio standard all'oggetto di notifica in tutti i programmi.
In questa situazione, utilizzare una combinazione univoca di identificazioni di utente e programma per
assicurare che il programma acceda alle informazioni corrette al suo riavvio.
Poiché le informazioni richieste per il riavvio potrebbero variare da programma a programma, non
utilizzare una struttura di dati descritta esternamente per l'identificazione di commit. Se viene utilizzato
un singolo oggetto di notifica, il precedente programma può descrivere la struttura di dati all'interno del
programma piuttosto che esternamente. Ad esempio:
1
11
21
24
30
50
52
10
20
23
29
49
51
220
0
USER
PGMNAM
PRODCT
LOCATN
DESC
QTY
DUMMY
In ogni programma che utilizza questo oggetto di notifica, le informazioni specificate per l'identificazione
di commit sono univoche per il programma (i nomi di utente e programma non sono univoci). L'oggetto
di notifica deve essere abbastanza grande da contenere la quantità massima di informazioni che un
programma può inserire nell'identificazione di commit.
100
IBM i: Database Controllo del commit
Concetti correlati
“Esempio: oggetto di notifica univoco per ciascun programma” a pagina 96
L'utilizzo di un singolo oggetto di notifica univoco per ciascun lavoro consente l'utilizzo di
un'identificazione di commit descritta esternamente anche se potrebbero esserci più utenti dello stesso
programma.
“Oggetto di notifica del commit” a pagina 53
Un oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioni
che identificano l'ultima transazione eseguita correttamente completata per una specifica definizione di
commit se tale definizione di commit non è stata terminata normalmente.
Esempio: utilizzo di un programma di elaborazione standard per
avviare un'applicazione
Un programma di elaborazione standard è un modo per riavviare l'applicazione utilizzando un singolo
file di database come oggetto di notifica per tutte le applicazioni. Questo approccio presume che i nomi
di profilo utente siano univoci in base all'utente per tutte le applicazioni che utilizzano il programma
standard.
Nota: utilizzando questo esempio di codice, si accettano i termini indicati nella sezione “Informazioni
sull'esonero di responsabilità e licenza del codice” a pagina 121.
Per questo approccio, il file fisico NFYOBJP viene utilizzato come oggetto di notifica e definito come:
Nome profilo utente univoco
Identificazione programma
Informazioni per riavvio
10 caratteri
10 caratteri
Campo caratteri
(Deve essere abbastanza grande
da contenere la quantità massima di
informazioni per riavviare
i programmi che richiedono informazioni
per il riavvio.
Questo campo è richiesto dai
programmi applicativi.
Nell'esempio, si presume che abbia
una lunghezza di 200).
Il file viene creato con SHARE(*YES). I primi due campi nel file sono la chiave per il file. (Questo file può
anche essere definito come una struttura di dati nei programmi RPG).
Concetti correlati
“Esempio: utilizzo di un file di registrazione delle transazioni per avviare un'applicazione” a pagina 90
Questo esempio fornisce il codice di esempio e le istruzioni su come utilizzare un file di registrazione
delle transazioni per avviare un'applicazione dopo una fine anomala.
Esempio: codice per un programma di elaborazione standard
Questo esempio mostra il codice per un programma di elaborazione standard che può essere utilizzato
per riavviare l'applicazione utilizzando un file di database come oggetto di notifica per tutte le
applicazioni.
L'applicazione presentata nel seguente esempio di codice esegue le seguenti operazioni:
1. Il programma applicativo riceve il nome utente in un parametro o lo utilizza con il nome programma
come un identificativo univoco nell'oggetto di notifica.
2. Il programma applicativo trasmette un codice di richiesta pari a R al programma di elaborazione di
commit standard, che determina se nell'oggetto di notifica è presente un record.
3. Se il programma di elaborazione di commit standard restituisce un codice pari a 1, significa che è
stato trovato un record e il programma applicativo presenta le informazioni necessarie per il riavvio
all'utente.
4. Il programma applicativo procede con la normale elaborazione.
Controllo del commit
101
5. Una volta completata una transazione, i valori vengono salvati per riferimento in modo che l'utente
della stazione di lavoro possa vedere le operazioni effettuate per la transazione precedente.
Le informazioni salvate non vengono fornite dall'oggetto di notifica perché l'oggetto idi notifica viene
aggiornato solo se si verifica un errore di lavoro o sistema.
Nota: utilizzando gli esempi di codice, si accettano i termini indicati nella sezione “Informazioni
sull'esonero di responsabilità e licenza del codice” a pagina 121.
Esempio di programma applicativo
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..
1.00
2.00
3.00
4.00
5.00
6.00
7.00
8.00
9.00
10.00
11.00
12.00
13.00
14.00
15.00
16.00
17.00
18.00
19.00
20.00
21.00
22.00
23.00
24.00
25.00
26.00
27.00
28.00
29.00
30.00
31.00
32.00
33.00
34.00
35.00
36.00
37.00
38.00
39.00
40.00
41.00
42.00
43.00
44.00
45.00
46.00
47.00
48.00
49.00
50.00
51.00
102
FPRDMSTP UF E
K
DISK
KCOMIT
FPRDLOCP UF E
K
DISK
KCOMIT
FPRDRCTD CF E
WORKSTN
F*
F* The following is a compile time array which contains the
F*
restart information used in the next example
F*
E
RTXT
50 50 1
Restart text
I*
I* Data structure used for info passed to notify object
I*
ICMTID
DS
I
1 10 USER
I
11 20 PGMNAM
I
21 23 PRODCT
I
24 29 LOCATN
I
30 49 DESCRP
I
P 50 510QTY
I
52 170 DUMMY
I
171 220 RSTART
C
*ENTRY
PLIST
C
PARM
USER10 10
C*
C* Initialize fields used to communicate with std program
C*
C
MOVE USER10
USER
C
MOVEL'PRDRC2' PGMNAM
C
MOVE 'R'
RQSCOD
Read Rqs
C
CALL 'STDCMT'
C
PARM
RQSCOD 1
C
PARM
RTNCOD 1
C
PARM
CMTID 220
Data struct
C
RTNCOD
IFEQ '1'
Restart
C
EXSR MOVLST
Move to last
C SETON
71
Restart
C
END
C*
C* Initialize fields used in notify object
C*
C
MOVEARTXT,1
RSTART
Move text
C*
C* Basic processing loop
C*
C
LOOP
TAG
C
EXFMTPROMPT
C 98
GOTO END
C
PRODCT
CHAINPRDMSTR
61
Not found
C 61
GOTO LOOP
C
KEY
KLIST
C
KFLD
PRODCT
C
KFLD
LOCATN
IBM i: Database Controllo del commit
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..
52.00
C
KEY
CHAINPRDLOCR
62
Not found
53.00
C
62
DO
54.00
C
EXCPTRLSMST
Release lck
55.00
C
GOTO LOOP
56.00
C
END
57.00
C
ADD QTY
ONHAND
Add
58.00
C
ADD QTY
LOCAMT
59.00
C
UPDATPRDMSTR
Update
60.00
C
UPDATPRDLOCR
Update
61.00
C*
62.00
C* Commit and move to previous fields
63.00
C*
64.00
C
CMTID
COMIT
65.00
C
EXSR MOVLST
Move to last
66.00
C
GOTO LOOP
67.00
C* End of program processing
68.00
C*
69.00
C
END
TAG
70.00
C
MOVE 'D'
RQSCOD
Dlt Rqs
71.00
C
CALL 'STDCMT'
72.00
C
PARM
RQSCOD
73.00
C
PARM
RTNCOD
74.00
C
PARM
CMTID
75.00
C
SETON
LR
76.00
C*
77.00
C* Move to -Last Used- fields for operator feedback
78.00
C*
79.00
C
MOVLST
BEGSR
80.00
C
MOVE PRODCT
LSTPRD
81.00
C
MOVE LOCATN
LSTLOC
82.00
C
MOVE DESCRP
LSTDSC
83.00
C
MOVE QTY
LSTQTY
84.00
C
ENDSR
85.00
OPRDMSTR E
RLSMST
86.00 ** RTXT
Restart Text
87.00 Inventory Menu - Receipts Option
Flusso di elaborazione:
Il programma standard viene richiamato dalle applicazioni che devono essere riavviate.
I programmi applicativi trasmettono questo elenco di parametri al programma standard:
v Codice di richiesta
v Codice di ritorno
v Nome della struttura dati (il contenuto dell'oggetto di notifica)
I codici di richiesta eseguono le seguenti operazioni:
v R (Lettura)
Richiama l'ultimo record aggiunto all'oggetto di notifica con la stessa chiave. Il codice di ritorno è
impostato come:
0
Non è disponibile alcun record (nessun riavvio richiesto).
1
Record restituito nel campo delle informazioni per il riavvio (riavvio richiesto).
v WA (Scrittura)
Scrive un record nel file. Questo codice può essere utilizzato se si utilizza un oggetto di notifica per
proprie attività. Ad esempio, se determina che la transazione deve essere riavviata, il programma può
scrivere un record per l'oggetto di notifica per simulare cosa farà il sistema se si verifica un
malfunzionamento di un lavoro o del sistema.
Controllo del commit
103
v DE (Cancellazione)
Cancella tutti i record nell'oggetto di notifica con la stessa chiave. Il codice di ritorno è impostato come:
0
Non esiste alcun record da cancellare.
1
Sono stati cancellati uno o più record.
v OE (Apertura)
Il codice richiesta O è facoltativo e viene utilizzato per evitare di dover avviare il programma di
elaborazione ogni volta che viene richiamato.
v CA (Chiusura)
Dopo che è stato utilizzato il codice di richiesta di apertura, l'utilizzo della richiesta di chiusura
assicura che il file venga chiuso.
v SA (Ricerca)
Restituisce l'ultimo record per questo utente. Il nome programma non viene utilizzato. Questo codice
può essere utilizzato in un programma iniziale per determinare se è richiesto il riavvio.
Esempio: codice per un programma di elaborazione di commit standard
Il programma di elaborazione di commit standard (STDCMT) esegue le funzioni richieste per comunicare
con un singolo oggetto di notifica utilizzato da tutte le applicazioni.
Mentre la funzione di controllo del commit scrive automaticamente una voce nell'oggetto di notifica, un
programma standard scritto dall'utente deve elaborare l'oggetto di notifica. Il programma standard
semplifica e standardizza l'approccio.
Il programma viene scritto per verificare i parametri trasmessi ed eseguire l'azione appropriata nel
seguente modo.
O=Apertura
Il programma chiamante richiede che il file di oggetto di notifica venga mantenuto aperto alla
restituzione. Poiché l'oggetto di notifica viene aperto implicitamente dal programma RPG, il
programma non lo deve chiudere. L'indicatore 98 viene impostato in modo che il programma
esegua la restituzione con LR disattivato per conservare le aree di lavoro del programma e lasci
l'oggetto di notifica aperto in modo che possa essere chiamato nuovamente senza un sovraccarico
eccessivo.
C=Chiusura
Il programma richiamante ha determinato che non ha più bisogno dell'oggetto di notifica e
richiede una chiusura. L'indicatore 98 è disattivato per consentire una chiusura completa
dell'oggetto di notifica.
R=Lettura
Il programma chiamante richiede che un record con dei campi chiave corrispondenti venga letto e
restituito. Il programma utilizza i campi chiave trasmessi per provare a richiamare un record da
NFYOBJP. Se esistono dei record duplicati per la stessa chiave, viene restituito l'ultimo record. Il
codice di ritorno viene impostato adeguatamente e, se il record esisteva, viene restituito nella
struttura di dati CMTID.
W=Scrittura
Il programma chiamante richiede che un record venga scritto nell'oggetto di notifica per
consentire il riavvio del programma chiamante la volta successiva che viene richiamato. Il
programma scrive il contenuto dei dati trasmessi come un record in NFYOBJP.
D=Cancellazione
Il programma chiamante richiede che i record per questa chiave corrispondente vengano
cancellati. Questa funzione viene di norma eseguita dopo il corretto completamento del
programma chiamante per eliminare le eventuali informazioni sul riavvio. Il programma prova a
cancellare i record per i campi chiave trasmessi. Se non esiste alcun record, viene restituito un
codice di ritorno differente.
104
IBM i: Database Controllo del commit
S=Ricerca
Il programma chiamante richiede una ricerca per un record per uno specifico utente,
indipendentemente da quale programma lo abbia scritto. Questa funzione viene utilizzata nel
programma per il collegamento per indicare che è richiesto il riavvio. Il programma utilizza solo
il nome utente come chiave per verificare se esistono i record. Il codice di ritorno viene impostato
in modo appropriato e il contenuto dell'ultimo record per questa chiave (se esiste) viene letto e
restituito.
Il seguente esempio mostra il programma di elaborazione di commit standard, STDCMT.
Programma di elaborazione di commit standard
Nota: utilizzando questo esempio di codice, si accettano i termini indicati nella sezione “Informazioni
sull'esonero di responsabilità e licenza del codice” a pagina 121.
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..
1.00
2.00
3.00
4.00
5.00
6.00
7.00
8.00
9.00
10.00
11.00
12.00
13.00
14.00
15.00
16.00
17.00
18.00
19.00
20.00
21.00
22.00
23.00
24.00
25.00
26.00
27.00
28.00
29.00
30.00
31.00
32.00
33.00
34.00
35.00
36.00
37.00
38.00
39.00
40.00
41.00
42.00
43.00
44.00
45.00
46.00
47.00
48.00
FNFYOBJP UF
ICMTID
I
I
I
C
C
C
C
C
C
C*
C* 'O' for
C*
C
C
C
C
C*
C* 'C' for
C*
C
C
C
C
C*
C* 'R' for
C*
C
C
C
C
C
C
51
C
51
C
C
C
C
20
C
C
C*
C* 'W' FOR
C*
C
C
C
C
E
DS
K
DISK
A
1 10 UNQUSR
11 20 UNQPGM
21 220 BIGFLD
*ENTRY
UNQUSR
UNQPGM
PLIST
PARM
PARM
PARM
CABEQ*BLANKS
CABEQ*BLANKS
RQSCOD 1
RTNCOD 1
CMTID 220
BADEND
BADEND
H1 Invalid
H2 Invalid
Open
RQSCOD
IFEQ 'O'
SETON
GOTO END
END
98
Open
End LR
Close
RQSCOD
IFEQ 'C'
SETOF
GOTO END
END
Close
98
Read - Get last record for the key
RQSCOD
KEY
KEY
LOOPl
KEY
IFEQ 'R'
KLIST
KFLD
KFLD
CHAINNFYOBJR
MOVE '0'
GOTO END
MOVE '1'
TAG
READENFYOBJR
GOTO END
GOTO LOOP1
END
Read
UNQUSR
UNQPGM
51
Not found
RTNCOD
RTNCOD
Found
20 EOF
Write
RQSCOD
IFEQ 'W'
WRITENFYOBJR
GOTO END
END
Write
Controllo del commit
105
49.00
50.00
51.00
52.00
53.00
54.00
55.00
56.00
57.00
58.00
59.00
60.00
61.00
62.00
63.00
64.00
65.00
66.00
67.00
68.00
69.00
70.00
71.00
72.00
73.00
74.00
75.00
76.00
77.00
78.00
79.00
80.00
81.00
82.00
83.00
84.00
85.00
86.00
87.00
88.00
89.00
C*
C*
C*
C
C
C
C
C
C
C
C
C
C
C
C*
C*
C*
C*
C
C
C
C
C
C
C
C
C
C
C*
C*
C*
C
C
C*
C*
C*
C
C
C
C*
C
'D' for Delete - Delete all records for the key
RQSCOD
KEY
51
51
LOOP2
KEY
N20
IFEQ 'D'
CHAINNFYOBJR
MOVE '0'
GOTO END
MOVE '1'
TAG
DELETNFYOBJR
READENFYOBJR
GOTO LOOP2
GOTO END
END
51
Delete
Not found
RTNCOD
RTNCOD
Found
20 EOF
'S' for Search for the last record for this user
(Ignore the -Program- portion of the key)
RQSCOD
UNQUSR
N20
N20
LOOP3
UNQUSR
N20
IFEQ 'S'
SETLLNFYOBJR
MOVE '0'
GOTO END
MOVE '1'
TAG
READENFYOBJR
GOTO LOOP3
GOTO END
END
Search
20 If equal
RTNCOD
RTNCOD
Found
20 EOF
Invalid request code processing
SETON
GOTO BADEND
H2
Bad RQS code
End of program processing
END
TAG
SETON
LR
RETRN
BADEND tag is used then fall thru to RPG cycle error return
BADEND
TAG
N98
Concetti correlati
“Esempio: utilizzo di un programma di elaborazione standard per decidere se riavviare l'applicazione”
Il programma iniziale può richiamare il programma di elaborazione di commit iniziale per determinare se
è necessario eseguire il riavvio. L'utente della stazione di lavoro può quindi decidere se eseguire il
riavvio.
Esempio: utilizzo di un programma di elaborazione standard per decidere se
riavviare l'applicazione
Il programma iniziale può richiamare il programma di elaborazione di commit iniziale per determinare se
è necessario eseguire il riavvio. L'utente della stazione di lavoro può quindi decidere se eseguire il
riavvio.
Il programma iniziale trasmette un codice di richiesta S (ricerca) al programma standard che ricerca un
eventuale record per l'utente. Se esiste un record, le informazioni per il riavvio vengono trasmesse al
programma iniziale e le informazioni vengono visualizzate per l'utente della stazione di lavoro.
L'identificazione di commit nell'oggetto di notifica contiene informazioni che il programma iniziale può
visualizzare identificando quale programma deve essere riavviato. Ad esempio, gli ultimi 50 caratteri
dell'identificazione di commit possono essere riservati per contenere queste informazioni. Nel programma
applicativo, queste informazioni possono trovarsi in una schiera al momento della compilazione ed essere
106
IBM i: Database Controllo del commit
spostate alla struttura di dati in un passo di inizializzazione. Esempio: codice per un programma di
elaborazione di commit standard che mostra come includere questa operazione nel programma
applicativo.
Il seguente esempio mostra un programma iniziale che determina se esiste un record nell'oggetto di
notifica.
Esempio: programma iniziale
Nota: utilizzando questo esempio di codice, si accettano i termini indicati nella sezione “Informazioni
sull'esonero di responsabilità e licenza del codice” a pagina 121.
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7
1.00
2.00
3.00
4.00
5.00
6.00
7.00
8.00
9.00
10.00
11.00
12.00
13.00
14.00
15.00
16.00
17.00
18.00
19.00
20.00
PGM
DCLF
DCL
DCL
DCL
DCL
DCL
RTVJOBA
CHGVAR
CALL
IF
CHGVAR
SNDRCVF
ENDDO
CMTINLD
&RQSCOD *CHAR LEN(1) VALUE(S) /* Search */
&RTNCOD *CHAR LEN(1)
&CMTID *CHAR LEN(220)
&USER *CHAR LEN(10)
&INFO *CHAR LEN(50)
USER(&USER)
&CMTID (&USER *CAT XX)
/* The XX is required to prevent a blank Pgm nam */
STDCMT PARM(&RQSCOD &RTNCOD &CMTID)
(&RTNCOD *EQ '1') DO /* RESTART REQD */
&INFO %SST(&CMTID 171 50)
RCDFMT(RESTART)
/*
/* Enter normal initial program statements
/*
or -TFRCTL- to first menu program
/*
*/
*/
*/
*/
ENDPGM
Concetti correlati
“Esempio: codice per un programma di elaborazione di commit standard” a pagina 104
Il programma di elaborazione di commit standard (STDCMT) esegue le funzioni richieste per comunicare
con un singolo oggetto di notifica utilizzato da tutte le applicazioni.
“Oggetto di notifica del commit” a pagina 53
Un oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioni
che identificano l'ultima transazione eseguita correttamente completata per una specifica definizione di
commit se tale definizione di commit non è stata terminata normalmente.
Risoluzione dei problemi relativi a transazioni e controllo del commit
Queste informazioni possono aiutare a risolvere gli errori di controllo del commit, rilevare le condizioni
di stallo, ripristinare le transazioni dopo un errore nelle transazioni, sapere quando forzare le operazioni
di commit e rollback e quando annullare la sincronizzazione e terminare i rollback a lunga esecuzione.
Errori del controllo del commit
Quando si utilizza il controllo del commit, è importante comprendere quali condizioni causano degli
errori e quali no.
In generale, gli errori si verificano quando le funzioni del controllo del commit vengono utilizzate in
modo non congruente, come ad esempio l'esecuzione di un comando ENDCMTCTL (Fine controllo
commit) quando i file che utilizzano la definizione di commit sono ancora aperti.
Controllo del commit
107
Errori durante l'elaborazione di commit
Se si verifica un errore di sistema o nelle comunicazioni durante un'operazione di commit, potrebbe
essere necessario eseguire la risincronizzazione per assicurare che i gestori transazioni mantengano i dati
congruenti su tutti i sistemi coinvolti nella transazione. La modalità di funzionamento della
risincronizzazione e il modo in cui essa influenza l'operazione di commit dipendono dai seguenti fattori:
v L'opzione di commit Attesa risultato.
v Lo stato della transazione.
Se l'errore è di entità tale da essere irreversibile, o se non può essere corretto nel tempo previsto, gli
operatori di sistema per gli altri sistemi coinvolti nella transazione devono prendere una decisione
euristica. La decisione euristica esegue il commit o il rollback delle modifiche apportate su tale sistema
durante la transazione. Se l'errore viene corretto dopo tale decisione, e la risincronizzazione rileva che la
decisione ha causato dei problemi di integrità dei dati, alla coda messaggi QSYSOPR viene inviato il
messaggio CPD83D9 o il messaggio CPD83E9.
Concetti correlati
“Definizione di commit per un commit in due fasi: Non attendere risultato” a pagina 37
Quando si verifica un malfunzionamento nelle comunicazioni o di sistema durante un'operazione di
commit, ed è quindi richiesta una risincronizzazione, il valore predefinito prevede di attendere che la
risincronizzazione sia terminata prima di completare l'operazione di commit.
“Stati della transazione per il controllo del commit a due fasi” a pagina 31
Una definizione di commit viene stabilita su ciascuna ubicazione che fa parte della rete del programma di
transazione. Per ciascuna definizione di commit, il sistema tiene traccia dello stato della sua transazione
corrente e della transazione precedente.
Condizioni di errore
Se si verifica un errore, viene inviato un messaggio di uscita per cui è possibile eseguire il monitoraggio
in un programma.
Sono qui di seguito riportati alcuni errori tipici correlati al controllo del commit:
v Vengono eseguiti dei comandi STRCMTCTL consecutivi senza un comando ENDCMTCTL intermedio.
v I file vengono aperti sotto il controllo del commit, ma non è stato eseguito alcun comando
STRCMTCTL.
Questa non è una condizione di errore per i programmi eseguiti in un gruppo di attivazione che
devono utilizzare la definizione di commit a livello di lavoro. La definizione di commit a livello di
lavoro può essere avviata solo da un singolo programma ma, quando viene avviata da un programma,
la definizione di commit a livello di lavoro viene utilizzata da qualsiasi programma in esecuzione in un
gruppo di attivazione che non sta utilizzando una definizione di commit a livello di gruppo di
attivazione. I programmi eseguiti in un gruppo di attivazione che devono utilizzare la definizione di
commit a livello di gruppo di attivazione devono prima avviare la definizione di commit a livello di
gruppo di attivazione con il comando STRCMTCTL.
v I file aperti per l'emissione sotto il controllo del commit non vengono registrati su giornale.
v La prima operazione di apertura di un file condiviso pone il file sotto il controllo del commit, cosa che
invece non fanno le successive operazioni di apertura dello stesso file condiviso.
v La prima operazione di apertura di un file condiviso non pone il file sotto il controllo del commit, cosa
che invece fanno le successive operazioni di apertura dello stesso file condiviso.
v Il limite di blocchi di record per il lavoro viene raggiunto in una singola transazione.
v Il programma emette un'operazione di lettura, un'operazione di commit e una modifica per lo stesso
record. L'operazione di lettura deve essere emessa nuovamente dopo l'operazione di commit perché
l'operazione di commit ha liberato il blocco sul record.
v Per un'ubicazione in una fase, le risorse poste sotto il controllo del commit non risiedono nella stessa
ubicazione delle risorse che già sono sotto il controllo del commit per la definizione di commit.
108
IBM i: Database Controllo del commit
v Delle modifiche di cui non è stato eseguito il commit esistono quando viene emesso un comando
ENDCMTCTL.
Questa non è una condizione di errore per il comando ENDCMTCTL se tutti i file sono chiusi,
l'eventuale database remoto è disconnesso e nessuna risorsa di commit API è ancora associata alla
definizione di commit da terminare.
v Viene eseguito un comando di commit, rollback o ENDCMTCTL e non è stato eseguito un comando
STRCMTCTL.
Questa non è una condizione di errore per i programmi eseguiti in un gruppo di attivazione e la
definizione di commit a livello di lavoro è attiva. La definizione di commit a livello di lavoro può
essere avviata solo da un singolo programma ma, quando viene avviata da un programma, la
definizione di commit a livello di lavoro viene utilizzata da qualsiasi programma in esecuzione in un
gruppo di attivazione che non sta utilizzando una definizione di commit a livello di gruppo di
attivazione. I programmi eseguiti in un gruppo di attivazione e che devono utilizzare la definizione di
commit a livello di gruppo di attivazione devono prima avviare la definizione di commit a livello di
gruppo di attivazione con il comando STRCMTCTL.
v Un comando ENDCMTCTL viene eseguito con i file ancora aperti sotto il controllo del commit per la
definizione di commit.
v Un lavoro che esegue un'operazione di salvataggio ha una o più definizioni di commit che non si
trovano a un limite di commit.
v Un'operazione di salvataggio durante l'utilizzo è terminata perché altri lavori con delle risorse di cui è
possibile eseguire il commit non hanno raggiunto un limite di commit nel tempo specificato per il
parametro SAVACTWAIT.
v Un processo di salvataggio durante l'utilizzo non è riuscito a continuare a causa di risorse di cui è
possibile eseguire il commit API aggiunte a più di una definizione di commit per un singolo lavoro.
v Più di 1023 definizioni di commit esistono per un singolo lavoro.
v La conversazione a un'ubicazione remota si interrompe a causa di un errore di risorsa. Questo può
causare l'esecuzione del rollback della transazione.
v Una risorsa in una fase aperta per l'aggiornamento è presente su un nodo che non ha iniziato
l'operazione di commit. È necessario rimuovere la risorsa o il nodo che ha iniziato la richiesta di
commit.
v Un'operazione di commit viene richiesta mentre la transazione è in uno stato di rollback richiesto
(RBR). È necessario eseguire un'operazione di rollback.
v Un programma di uscita API emette una richiesta di commit o una richiesta di rollback.
v Un programma di trigger emette una richiesta di commit o una richiesta di rollback per la definizione
di commit sotto cui è stato richiamato il programma di trigger.
Il programma di trigger può avviare una definizione di commit separata e emettere una richiesta di
commit o di rollback per tale definizione.
Condizioni senza errori
Sono qui di seguito riportate alcune situazioni per il controllo del commit in cui non si verificano errori.
v Un'operazione di commit o di rollback viene eseguita e nessuna risorsa è sotto il controllo del commit.
Questo consente di includere le operazioni di commit o di rollback nel programma senza considerare
se ci sono risorse sotto il controllo del commit. Consente anche di specificare un'identificazione di
commit prima di eseguire modifiche di cui è possibile eseguire il commit.
v Un'operazione di commit o di rollback viene eseguita e non ci sono modifiche di risorse di cui non è
stato eseguito il commit. Questo consente di includere le operazioni di commit e rollback nel
programma senza considerare se ci sono delle modifiche di risorse di cui non è stato eseguito il
commit.
v Un file sotto il controllo del commit viene chiuso ed esistono dei record di cui non è stato eseguito il
commit. Questa situazione consente a un altro programma di essere richiamato per eseguire
l'operazione di commit o di rollback. Questo si verifica indipendentemente dal fatto che il file sia
Controllo del commit
109
condiviso o meno. Questa funzione consente a un programma secondario di apportare delle modifiche
al database che fanno parte di una transazione che interessa più programmi.
v Un lavoro termina, in modo normale o anomalo, con delle modifiche di cui non è stato eseguito il
commit per una o più definizioni di commit. Viene eseguito il rollback delle modifiche per tutte le
definizioni di commit.
v Un gruppo di attivazione termina con delle modifiche in sospeso per la definizione di commit a livello
di gruppo di attivazione. Se il gruppo di attivazione sta terminando in modo normale e non sono stati
rilevati degli errori alla chiusura dei file aperti sotto il controllo del commit incluso nell'ambito dello
stesso gruppo di attivazione che sta terminando, il sistema esegue un commit implicito. Altrimenti,
viene eseguito un rollback implicito.
v Un programma accede nuovamente a un record modificato di cui non è stato eseguito il commit.
Questo consente a un programma di:
– Aggiungere un record e aggiornarlo prima di specificare l'operazione di commit.
– Aggiornare lo stesso record due volte prima di specificare l'operazione di commit.
– Aggiungere un record e cancellarlo prima di specificare l'operazione di commit.
– Accedere nuovamente a un record di cui non è stato eseguito il commit da un file logico differente
(sotto il controllo del commit).
v Si specifica LCKLVL(*CHG o *CS) nel comando STRCMTCTL e si apre un file con un'operazione di
commit per la sola lettura. In questo caso, non si verifica alcun blocco sulla richiesta. Ne viene eseguita
l'elaborazione come se il controllo del commit non fosse effettivo ma il file non compare nell'opzione di
menu WRKJOB di file sotto il controllo del commit.
v Si emette il comando STRCMTCTL e non si apre alcun file sotto il controllo del commit. In questa
situazione, qualsiasi modifica a livello di record apportata ai file non viene eseguita sotto il controllo
del commit.
Messaggi di errore da monitorare durante il controllo del commit
Diversi messaggi di errore differenti possono essere restituiti dalle operazioni di commit o rollback o
inviati alla registrazione lavoro, a seconda del tipo di messaggio e di quando si è verificato l'errore.
I messaggi di errore possono essere generati durante la seguente elaborazione:
v Elaborazione di commit o rollback normale
v Elaborazione di commit o rollback durante la fine dell'elaborazione del lavoro
v Elaborazione di commit o rollback durante la fine del gruppo di attivazione
Non è possibile eseguire il monitoraggio per i seguenti messaggi di errore durante la fine del gruppo di
attivazione o la fine dell'elaborazione del lavoro. Inoltre, è possibile eseguire il monitoraggio solo per i
messaggi CPFxxxx. I messaggi CPDxxxx sono sempre inviati come messaggi diagnostici di cui non è
possibile eseguire il monitoraggio. Eventuali errori rilevati quando si termina una definizione di commit a
livello di gruppo di attivazione durante la terminazione del gruppo di attivazione o la fine di eventuali
definizioni di commit durante la terminazione del lavoro sono lasciati nella registrazione lavoro come
messaggi di diagnostica.
I messaggi di errore correlati al controllo del commit da cercare sono i seguenti:
CPD8351
Le modifiche potrebbero non essere state sottoposte a commit.
CPD8352
Modifiche non sottoposte a commit all'ubicazione remota &3.
CPD8353
Le modifiche al database relazionale &1 potrebbero non essere state sottoposte a commit.
CPD8354
Le modifiche al file DDM & 1 potrebbero non essere state sottoposte a commit.
110
IBM i: Database Controllo del commit
CPD8355
Le modifiche all'oggetto DDL di tipo &1 potrebbero non essere state sottoposte a commit.
CPD8356
Le modifiche di cui è stato effettuato il rollback potrebbero essere state sottoposte a commit.
CPD8358
È probabile che non sia stato eseguito il rollback delle modifiche ad un database relazionale &1.
CPD8359
È probabile che non sia stato eseguito il rollback delle modifiche al file DDM &1.
CPD835A
È probabile che non sia stato eseguito il rollback delle modifiche ad un oggetto DDL &3.
CPD835C
Oggetto di notifica &1 in &2 non aggiornato.
CPD835D
La risorsa DRDA non consente il congelamento del cursore SQL.
CPF835F
L'operazione di commit o di rollback ha avuto esito negativo.
CPD8360
I membri, i file o entrambi sono già stati disallocati.
CPD8361
Errore del programma di uscita API &1 durante il commit.
CPD8362
Il programma di uscita API &1 ha riportato un errore durante l'elaborazione di rollback.
CPD8363
Il programma di uscita API &1 è terminato dopo &4 minuti durante il commit.
CPD8364
Il programma di uscita API &1 è terminato dopo &4 minuti durante il rollback.
CPD836F
Errore del protocollo durante l'operazione di controllo del commit.
CPD83D1
La risorsa API &4 non può essere l'ultimo agent.
CPD83D2
Risorsa incompatibile con il controllo del commit.
CPD83D7
L'operazione di commit è stata modificata in quella di rollback.
CPD83D9
Si è verificata una condizione euristica mista.
CPF83DB
L'operazione di commit ha causato il rollback.
CPD83DC
'Azione in caso di problemi' è stata utilizzata per stabilire un'operazione di commit o rollback;
causa &2.
CPD83DD
La conversazione è terminata; causa &1.
CPD83DE
Le informazioni di ritorno non sono valide.
Controllo del commit
111
CPD83EC
Il programma di uscita API &1 ha stabilito il rollback.
CPD83EF
È stato avviato il rollback dell'unità logica di lavoro successiva.
CPF8350
Definizione di commit non trovata.
CPF8355
ENDCMTCTL non è consentito. Sono presenti delle modifiche in sospeso.
CPF8356
Il controllo del commit è terminato con &1 modifiche non sottoposte a commit.
CPF8358
Oggetto di notifica &1 in &2 non aggiornato.
CPF8359
L'operazione di rollback ha avuto esito negativo.
CPF835A
La chiusura della definizione di commit &1 è stata annullata.
CPF835B
Si sono verificati degli errori durante la chiusura del controllo del commit.
CPF835C
Il controllo del commit è terminato con le modifiche remote non sottoposte a commit.
CPF8363
L'operazione di commit non è riuscita.
CPF8364
Il valore del parametro relativo al controllo del commit non è valido. Il codice errore è &3.
CPF8367
Non è possibile eseguire l'operazione di controllo del commit.
CPF8369
Non è possibile porre la risorsa di commit API sotto controllo del commit; codice di errore &1.
CPF83D0
L'operazione di commit non è consentita.
CPF83D2
Commit completato == La risincronizzazione in corso è stata restituita.
CPF83D3
Commit completato == È stato restituita l'operazione Euristica mista.
CPF83D4
La voce di giornale dell'unità logica di lavoro non è stata inviata.
CPF83E1
L'operazione di commit ha avuto esito negativo a causa di una violazione di restrizione.
CPF83E2
Si richiede l'operazione di rollback.
CPF83E3
Il livello di nidificazione richiesto non è attivo.
CPF83E4
Il controllo del commit è terminato con delle risorse non sottoposte a commit.
112
IBM i: Database Controllo del commit
CPF83E6
Operazione controllo del commit completata con risincronizzazione in corso.
CPF83E7
Convalida o ripristino non consentito per la transazione globale X/Open non consentiti.
Monitoraggio del verificarsi di errori dopo un comando CALL
Quando viene richiamato un programma che utilizza il controllo del commit, monitorare se si verificano
degli errori imprevisti ed eseguire un'operazione di rollback, se si verifica un errore.
Ad esempio, dei record di cui non è stato eseguito il commit possono esistere quando un programma
rileva un errore imprevisto come ad esempio un errore di divisione per zero RPG.
In base allo stato del parametro di Risposta al messaggio di interrogazione (INQMSGRPY) per un lavoro,
il programma invia un messaggio di interrogazione o esegue un'azione predefinita. Se la risposta
dell'operazione oppure l'azione predefinita terminano il programma, i record di cui non è stato eseguito il
commit continuano a esistere, in attesa di un'operazione di commit o di rollback.
Se viene richiamato un altro programma che determina un'operazione di commit, viene eseguito il
commit della transazione completata parzialmente dal programma precedente.
Per evitare che venga eseguito il commit di transazioni completate parzialmente, monitorare la
generazione di eventuali messaggi di escape dopo il comando CALL. Ad esempio, se si tratta di un
programma RPG, utilizzare la seguente codifica:
CALL RPGA
MONMSG MSGID(RPG9001)
EXEC(ROLLBACK) /*Rollback if pgm is canceled*/
Se si tratta di un programma COBOL:
CALL COBOLA
MONMSG MSGID(CBE9001)
EXEC(ROLLBACK) /*Rollback if pgm is canceled*/
Errore di elaborazione di commit o rollback normale
Durante l'elaborazione di commit o rollback, possono verificarsi degli errori in qualsiasi momento.
La seguente tabella divide questa elaborazione in quattro situazioni. La colonna di mezzo descrive le
azioni eseguite dal sistema quando rileva degli errori durante ciascuna situazione. La terza colonna
suggerisce cosa l'utente o l'applicazione devono fare in risposta ai messaggi. Questi consigli sono
congruenti con il modo in cui l'elaborazione di controllo del commit è gestita dal sistema.
Situazione
Elaborazione di commit o rollback
Azione suggerita
Il commit di I/E a livello di record
ha esito negativo
Monitoraggio della generazione di
v Se l'errore si verifica durante la
fase di preparazione, la transazione messaggi; gestire come desiderato
viene sottoposta a rollback e viene
inviato il messaggio CPF83DB.
v Se l'errore si verifica durante la
fase di commit, l'elaborazione di
commit continua ad eseguire il
commit del massimo numero di
risorse rimanenti possibile. Il
messaggio CPF8363 viene inviato
alla fine dell'elaborazione di
commit.
Controllo del commit
113
Situazione
Elaborazione di commit o rollback
Azione suggerita
Monitoraggio della generazione di
Malfunzionamento durante il commit v Se l'errore si verifica durante la
del programma di uscita di commit e
fase di preparazione, la transazione messaggi; gestire come desiderato
di rollback o a livello di oggetto per
viene sottoposta a rollback e viene
la risorsa di commit API
inviato il messaggio CPF83DB.
v Se l'errore si verifica durante la
fase di commit, l'elaborazione
continua ad eseguire il commit o il
rollback del massimo numero di
risorse rimanenti possibile. A
seconda del tipo di risorsa di
commit, viene restituito uno dei
seguenti messaggi:
– CPD8353
– CPD8354
– CPD8355
– CPD8361
Il messaggio CPF8363 viene inviato
alla fine dell'elaborazione di
commit.
Il rollback di I/E a livello di record
ha esito negativo
1. Restituisce CPD8356
2. Provare a continuare
l'elaborazione per eseguire il
rollback di risorse di commit API
o a livello di oggetto
Monitoraggio della generazione di
messaggi; gestire come desiderato
3. Restituisce CPF8359 alla fine
dell'elaborazione
Malfunzionamento durante il rollback 1. A seconda del tipo di risorsa di
del programma di uscita di commit e
commit, restituisce uno dei
di rollback o a livello di oggetto per
seguenti messaggi:
le risorse di commit API
v CPD8358
Monitoraggio della generazione di
messaggi; gestire come desiderato
v CPD8359
v CPD835A
v CPD8362
2. Continua l'elaborazione
3. Restituisce CPF8359 alla fine
dell'elaborazione
Elaborazione di commit o rollback durante la terminazione del lavoro
Tutte le situazioni descritte nella tabella precedente sono valide anche durante la terminazione di un
lavoro, tranne per il fatto che viene inviato uno dei seguenti messaggi:
v CPF8356 se sono registrate solo le risorse locali
v CPF835C se sono registrate solo le risorse remote
v CPF83E4 se sono registrate sia le risorse locali sia quelle remote
Inoltre, potrebbe essere visualizzato uno dei due messaggi specifici per il completamento del lavoro se è
stato richiamato un programma di uscita di commit e rollback per una risorsa di cui è possibile eseguire
il commit API. Se il programma di uscita di commit e rollback non viene completato entro 5 minuti viene
annullato; viene inviato un messaggio di diagnostica CPD8363 (per il commit) o CPD8364 (per il rollback)
e il resto dell'elaborazione di commit o di rollback continua.
114
IBM i: Database Controllo del commit
Elaborazione di commit o di rollback durante l'IPL (initial program load)
Tutte le situazioni descritte nella tabella precedente si applicano anche durante il ripristino IPL per le
definizioni di commit, tranne per il fatto che viene inviato il messaggio CPF835F invece del messaggio
CPF8359 o CPF8363. I messaggi inviati per una specifica definizione di commit possono essere presenti
nella registrazione lavoro per uno dei lavori QDBSRVxx o nella registrazione QHST. Nella registrazione
QHST, il messaggio CPI8356 indica l'inizio del ripristino IPL per una specifica definizione di commit. Il
messaggio CPC8351 indica la fine del ripristino IPL per una specifica definizione di commit e qualsiasi
altro messaggio relativo al ripristino di tale definizione di commit si trova tra questi due messaggi.
Potrebbe essere visualizzato uno dei due messaggi specifici per una definizione di commit, se è stato
richiamato un programma di uscita di commit e rollback per una risorsa di cui è possibile eseguire il
commit API. Se il programma di uscita di commit e rollback non viene completato entro 5 minuti viene
annullato; viene inviato un messaggio di diagnostica CPD8363 (per il commit) o CPD8364 (per il rollback)
e il resto dell'elaborazione di commit o di rollback continua.
Rilevazione di condizioni di stallo
Una condizione di stallo può verificarsi quando un lavoro detiene un blocco su un oggetto, l'oggetto A, e
sta attendendo di ottenere un blocco su un altro oggetto, l'oggetto B. Contemporaneamente, un altro
lavoro o un'altra transazione attualmente detiene un blocco sull'oggetto B e sta attendendo di ottenere un
blocco sull'oggetto A.
Attenersi alla seguente procedura per determinare se si è verificata una condizione di stallo e, in caso
affermativo, correggerla:
1. Individuare il lavoro sospeso nell'elenco di lavori attivi.
2. Consultare gli oggetti che il lavoro sta attendendo di bloccare.
3. Per tutti gli oggetti che il lavoro sta attendendo di bloccare, consultare l'elenco di detentori di blocchi
(transazioni o lavori) e provare a trovare un blocco in conflitto che corrisponde al livello richiesto dal
lavoro sospeso.
4. Se una transazione sta detenendo un blocco in conflitto, visualizzare i lavori associati a questa
transazione e verificare se uno di essi sta attendendo di bloccare.
5. Determinare se il lavoro in attesa sta provando a bloccare uno degli oggetti bloccati dal lavoro
sospeso iniziale. Quando si trova il lavoro che sta provando a bloccare uno degli oggetti bloccati dal
lavoro sospeso iniziale, è possibile identificare gli oggetti in questione come possibili cause di
problemi.
6. Esaminare la transazione per determinare l'appropriato corso di azione.
a. Consultare le proprietà della transazione per appurare quale applicazione l'ha iniziata e consultare
quindi il codice applicazione.
b. In alternativa, tracciare le azioni della transazione fino a questo punto trovando l'ID di ciclo di
commit nelle proprietà della transazione e cercando quindi in un giornale le voci che contengono
questo ID. Per eseguire questa operazione, è possibile utilizzare il comando RTVJRNE (Richiamo
voce di giornale) e specificare il parametro CMTCYCID.
c. Dopo aver ottenuto informazioni pertinenti, è possibile scegliere di forzare un'operazione di
rollback o di commit.
Controllo del commit
115
Attività correlate
“Riduzione al minimo dei blocchi” a pagina 74
Un modo tipico per ridurre al minimo i blocchi di record consiste nel rilasciare il blocco di record.
(Questa tecnica non funziona se è stato specificato LCKLVL(*ALL)).
Determining the status of a job
“Visualizzazione di oggetti bloccati per una transazione” a pagina 70
È possibile visualizzare degli oggetti bloccati per le transazioni globali solo con i blocchi nell'ambito della
transazione.
“Visualizzazione di lavori associati a una transazione” a pagina 70
Per visualizzare i lavori associati a una transazione, attenersi alla seguente procedura.
“Visualizzazione delle informazioni sul controllo del commit” a pagina 69
System i Navigator può visualizzare informazioni su tutte le transazioni (unità di lavoro logiche) sul
sistema. System i Navigator può anche visualizzare eventuali informazioni sul lavoro associate a una
transazione.
“Quando forzare le opzioni di commit e di rollback e quando annullare la risincronizzazione” a pagina
117
La decisione di forzare un'operazione di commit o di rollback viene detta decisione euristica. Questa azione
abilita un operatore ad eseguire il commit o il rollback manualmente delle risorse per una transazione che
è in uno stato Preparato.
“Ricerca di transazioni di grandi dimensioni oppure obsolete” a pagina 119
Utilizzare il comando WRKCMTDFN (Gestione definizioni di commit) per trovare transazioni di grandi
dimensioni oppure obsolete.
Riferimenti correlati
Retrieve Journal Entry (RTVJRNE) command
Ripristino delle transazioni dopo un errore nelle comunicazioni
Queste istruzioni aiutano a gestire le transazioni che eseguono delle attività su un sistema remoto dopo
che si è verificato un errore nelle comunicazioni con tale sistema.
Nel caso di un errore nelle comunicazioni, il sistema di norma completa la risincronizzazione con i
sistemi remoti automaticamente. Tuttavia, se l'errore è talmente grave che le comunicazioni con il sistema
remoto non verranno mai ristabilite (ad esempio se la linea di comunicazione viene interrotta), è
necessario annullare la risincronizzazione e ripristinare le transazioni personalmente. Le transazioni
potrebbero anche detenere dei blocchi che devono essere rilasciati.
1. In System i Navigator, visualizzare le informazioni sul controllo del commit per la transazione con cui
si sta lavorando.
2. Trovare la transazione cui si è interessati che sta provando ad eseguire la risincronizzazione con il
sistema remoto. Il campo Risincronizzazione in corso per tale transazione è impostato su sì.
3. Cercare le transazioni che avevano una connessione al sistema remoto controllando lo stato della
risorsa per le singole transazioni.
4. Dopo aver identificato le transazioni, è necessario forzare il commit o il rollback, a seconda dello stato
della transazione.
5. È possibile decidere per l'esecuzione del commit o del rollback dopo aver esaminato le proprietà della
transazione.
v È possibile utilizzare l'ID unità di lavoro per trovare altre parti della transazione su altri sistemi.
v È anche possibile determinare l'esecuzione del commit o del rollback dallo stato della transazione.
Ad esempio, se una transazione del database sta eseguendo un commit in due fasi durante un
errore nelle comunicazioni e il suo stato dopo l'errore è "preparato" o "ultimo agent in sospeso", è
possibile scegliere di forzare il commit sulla transazione.
6. Dopo la forzatura di un commit o un rollback sulle transazioni in dubbio, arrestare la
risincronizzazione sulla connessione in errore per le transazioni identificate.
116
IBM i: Database Controllo del commit
Attività correlate
“Visualizzazione delle informazioni sul controllo del commit” a pagina 69
System i Navigator può visualizzare informazioni su tutte le transazioni (unità di lavoro logiche) sul
sistema. System i Navigator può anche visualizzare eventuali informazioni sul lavoro associate a una
transazione.
“Quando forzare le opzioni di commit e di rollback e quando annullare la risincronizzazione”
La decisione di forzare un'operazione di commit o di rollback viene detta decisione euristica. Questa azione
abilita un operatore ad eseguire il commit o il rollback manualmente delle risorse per una transazione che
è in uno stato Preparato.
Quando forzare le opzioni di commit e di rollback e quando annullare
la risincronizzazione
La decisione di forzare un'operazione di commit o di rollback viene detta decisione euristica. Questa azione
abilita un operatore ad eseguire il commit o il rollback manualmente delle risorse per una transazione che
è in uno stato Preparato.
Quando si prende una decisione euristica, lo stato della transazione diviene euristicamente mista se la
propria decisione non è congruente con i risultati delle altre ubicazioni nella transazione. È necessario
assumersi l'onere di determinare l'azione eseguita da tutte le altre ubicazioni che hanno partecipato alla
transazione e di risincronizzare i record di database.
Prima di prendere una decisione euristica, raccogliere tutte le informazioni possibili sulla transazione.
Visualizzare i lavori associati alla definizione di commit e creare un record che indica i giornali e i file
interessati. È possibile utilizzare queste informazioni successivamente se si devono visualizzare le voci di
giornale e applicare o eliminare modifiche registrate su giornale manualmente.
Un punto ottimale di reperimento di informazioni su una transazione è l'ubicazione che ha iniziato tale
transazione. Tuttavia, la decisione di eseguire il commit o il rollback potrebbe appartenere a una risorsa
API o a un ultimo agent.
Se una risorsa API è stata registrata come una risorsa ultimo agent, la decisione finale di eseguire il
commit o il rollback appartiene alla risorsa API. È necessario verificare le informazioni sull'applicazione e
su come utilizza la risorsa API per determinare se eseguire il commit o il rollback.
Se per la transazione è selezionato un ultimo agent, la decisione di eseguire il commit o il rollback
appartiene all'ultimo agent. Consultare lo stato dell'ultimo agent per informazioni sulla transazione.
Quando è necessario prendere delle decisioni euristiche o annullare la risincronizzazione a causa di un
errore di sistema o nelle comunicazioni che non è possibile riparare, è possibile trovare tutte le
transazioni in dubbio attenendosi alla seguente procedura:
1. In System i Navigator, espandere il sistema che si desidera gestire.
2. Espandere Database e il database locale per il sistema.
3. Espandere Transazioni.
4. Espandere Transazioni database o Transazioni globali.
In queste finestre di visualizzazione, è possibile vedere la definizione di commit, lo stato di
risincronizzazione, l'ID di unità di lavoro corrente e lo stato dell'unità di lavoro corrente per ciascuna
transazione. Cercare le transazioni con le seguenti informazioni:
v Transazioni con uno Stato unità logica di lavoro di Preparato o Ultimo agent in sospeso.
v Transazioni che mostrano uno stato di Risincronizzazione in corso impostato su sì.
Controllo del commit
117
Per gestire il lavoro che sta partecipando nella transazione di questo sistema, fare clic con il tasto destro
del mouse sulla transazione e selezionare lavoro.
Quando si fa clic con il tasto destro del mouse sulla transazione, è anche possibile selezionare Forza
commit, Forza rollback o Annulla risincronizzazione.
Prima di prendere una decisione euristica o di annullare la risincronizzazione, è opportuno controllare lo
stato dei lavori sugli altri sistemi associati alla transazione. Controllare i lavori sui sistemi remoti può
aiutare ad evitare decisioni che causano incongruenze del database tra i sistemi.
1. Fare clic con il tasto destro del mouse sulla transazione che si desidera gestire.
2. Selezionare Stato risorsa.
3. Nella finestra di dialogo Stato risorsa, selezionare la scheda Conversazione per le connessioni SNA;
selezionare Connessione per le connessioni TCP/IP.
Ciascuna risorsa di conversazione rappresenta un sistema remoto che sta partecipando alla transazione.
Sui sistemi remoti, è possibile utilizzare System i Navigator per visualizzare le transazioni associate alla
transazione.
La parte di base dell'ID dell'unità di lavoro è uguale su tutti i sistemi. Quando si visualizzano le
informazioni sul controllo del commit sul sistema remoto, cercare la parte di base dell'ID dell'unità di
lavoro che è uguale sul sistema locale.
Ad esempio, se l'ID dell'unità di lavoro sul sistema locale inizia con: APPN.RCHASL97.X'112233445566,
cercare l'ID dell'unità di lavoro sul sistema remoto che inizia anch'esso con
APPN.RCHASL97.X'112233445566.
Concetti correlati
“Supporto delle transazioni XA per il controllo del commit” a pagina 46
DB2 for i può partecipare nelle transazioni globali X/Open.
“Avvio del controllo del commit” a pagina 52
Per avviare il controllo del commit, utilizzare il comando STRCMTCTL (Avvio controllo commit).
Attività correlate
“Rilevazione di condizioni di stallo” a pagina 115
Una condizione di stallo può verificarsi quando un lavoro detiene un blocco su un oggetto, l'oggetto A, e
sta attendendo di ottenere un blocco su un altro oggetto, l'oggetto B. Contemporaneamente, un altro
lavoro o un'altra transazione attualmente detiene un blocco sull'oggetto B e sta attendendo di ottenere un
blocco sull'oggetto A.
“Ripristino delle transazioni dopo un errore nelle comunicazioni” a pagina 116
Queste istruzioni aiutano a gestire le transazioni che eseguono delle attività su un sistema remoto dopo
che si è verificato un errore nelle comunicazioni con tale sistema.
“Visualizzazione delle informazioni sul controllo del commit” a pagina 69
System i Navigator può visualizzare informazioni su tutte le transazioni (unità di lavoro logiche) sul
sistema. System i Navigator può anche visualizzare eventuali informazioni sul lavoro associate a una
transazione.
Fine di un rollback a lunga esecuzione
È possibile terminare i rollback a lunga esecuzione che consumano tempo del processore critico, bloccano
risorse o utilizzano spazio di memorizzazione.
Un'operazione di rollback elimina tutte le modifiche apportate in una transazione dopo la precedente
operazione di commit o di rollback. Durante un'operazione di rollback, il sistema rilascia anche i blocchi
correlati alla transazione. Se contiene migliaia di transazioni, il sistema impiega ore per completare
un'operazione di rollback. Questi rollback a lunga esecuzione possono consumare tempo del processore
critico, bloccare risorse o utilizzare spazio di memorizzazione.
118
IBM i: Database Controllo del commit
Prima di terminare un rollback a lunga esecuzione, è necessario sapere quali sono le definizioni di
commit di cui si sta eseguendo il rollback e qual è il loro stato. Il campo relativo allo stato per le
definizioni di commit di cui è in corso il rollback è impostato su ROLLBACK IN CORSO.
Utilizzare il comando WRKCMTDFN (Gestione definizioni di commit) per controllare lo stato di un
rollback attenendosi alla seguente procedura:
1. Immettere WRKCMTDFN JOB(*ALL) dall'interfaccia basata sui caratteri.
2. Immettere F11 per visualizzare il campo Stato.
Se si termina un rollback a lunga esecuzione, i file che erano stati modificati durante la transazione
verranno lasciati con delle transazioni parziali. Non si deve terminare un rollback se i file non possono
avere delle transazioni parziali. Per appurare quali sono i file che erano stati modificati durante la
transazione, scegliere l'opzione 5 per visualizzare lo stato dall'elenco WRKCMTDFN. Premere F6 per
visualizzare lo stato della risorsa e selezionare Livello record.
È necessario disporre dell'autorizzazione speciale a tutti gli oggetti (*ALLOBJ) per terminare un rollback a
lunga esecuzione. Per terminare un rollback a lunga esecuzione, attenersi alla seguente procedura:
1. Immettere WRKCMTDFN JOB(*ALL) dall'interfaccia basata sui caratteri.
2. Immettere l'opzione 20 (Fine rollback) sulla definizione di commit che si desidera terminare.
I file con delle transazioni parziali hanno il campo Presenza transazione parziale, rollback terminato
impostato su *YES nell'emissione dal comando DSPFD (Visualizzazione descrizione file). È necessario
rimuovere le transazioni parziali prima che il file possa essere utilizzato. È possibile rimuovere le
transazioni parziali eliminando il file e ripristinandolo da un salvataggio precedente. Se non si dispone di
un salvataggio precedente, è possibile utilizzare il comando CHGJRNOBJ (Modifica oggetto registrato su
giornale) per reimpostare lo stato Presenza transazione parziale in modo da poter aprire il file. L'utilizzo
di CHGJRNOBJ richiede che si modifichi il file per portarlo a uno stato congruente. È necessario
utilizzare il comando CHGJRNOBJ solo se non è disponibile un salvataggio precedente.
Disabilitazione della capacità di terminare un rollback a lunga esecuzione
Gli utenti con l'autorizzazione speciale *ALLOBJ possono terminare i rollback per impostazione
predefinita. Se si desidera impedire agli utenti che hanno l'autorizzazione speciale *ALLOBJ di terminare
i rollback, è possibile farlo creando l'area dati QGPL/QTNNOENDRB.
Riferimenti correlati
Create Data Area (CRTDTAARA) command
|
Ricerca di transazioni di grandi dimensioni oppure obsolete
|
|
Utilizzare il comando WRKCMTDFN (Gestione definizioni di commit) per trovare transazioni di grandi
dimensioni oppure obsolete.
|
|
Per trovare delle transazioni di grandi dimensioni oppure obsolete, attenersi alla seguente procedura:
|
|
|
|
|
|
|
|
|
|
1. Immettere WRKCMTDFN JOB(*ALL) OUTPUT(*PRINT) dall'interfaccia basata sui caratteri.
2. Utilizzare il comando WRKSPLF per gestire i file di spool.
3. Utilizzare l'opzione 5=Visualizz. per visualizzare il file di spool creato dal comando WRKCMTDFN al
passo 1.
4. Per trovare delle transazioni di grandi dimensioni, cercare i campi 'Blocchi record' e 'Modifiche in
sospeso' visualizzati nella sezione Visualizzazione dello stato del giornale per ciascuna definizione di
commit. Questi campi mostrano il numero totale di blocchi di record e di modifiche in sospeso
attualmente per la transazione.
5. Per trovare delle transazioni obsolete, cercare il campo 'Registrazione data/ora' nella sezione Stato
controllo del commit per ciascuna definizione di commit. Questo campo mostra quando è stata
avviata la transazione.
Controllo del commit
119
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Queste informazioni sono visualizzate anche quando si utilizza System i® Navigator o IBM Systems
Director Navigator per i per visualizzare le transazioni, ma è più facile trovare le transazioni di grandi
dimensioni oppure obsolete cercando nel singolo file di spool prodotto dal comando WRKCMTDFN
invece di visualizzare le proprietà e lo stato risorsa per ciascuna transazione.
Attività correlate
“Rilevazione di condizioni di stallo” a pagina 115
Una condizione di stallo può verificarsi quando un lavoro detiene un blocco su un oggetto, l'oggetto A, e
sta attendendo di ottenere un blocco su un altro oggetto, l'oggetto B. Contemporaneamente, un altro
lavoro o un'altra transazione attualmente detiene un blocco sull'oggetto B e sta attendendo di ottenere un
blocco sull'oggetto A.
“Visualizzazione delle informazioni sul controllo del commit” a pagina 69
System i Navigator può visualizzare informazioni su tutte le transazioni (unità di lavoro logiche) sul
sistema. System i Navigator può anche visualizzare eventuali informazioni sul lavoro associate a una
transazione.
Informazioni correlate per il controllo del commit
I manuali dei prodotti, le pubblicazioni IBM Redbooks, i siti Web e altre raccolte di argomenti
dell'information center contengono informazioni correlate alla raccolta di argomenti Controllo del commit.
È possibile visualizzare o stampare qualsiasi file PDF.
Manuali
I seguenti manuali non sono inclusi nell'Information Center i5/OS V6R1. Tuttavia, questi manuali
potrebbero contenere utili informazioni di riferimento. Ciascuno dei manuali è disponibile dal sito IBM
come copia cartacea
Publications Center (www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss?)
stampata che è possibile ordinare, nel formato in linea che è possibile scaricare gratuitamente o in
entrambi i formati.
v COBOL/400 User's Guide
v RPG/400 User's Guide
IBM Redbooks
v Advanced Functions and Administration on DB2 for i
(5529 KB)
v Stored Procedures, Triggers, and User Defined Functions on DB2 for i
v Striving for Optimal Journal Performance on DB2 for i
Siti Web
v The Open Group (www.opengroup.org)
Ulteriori informazioni
v Database programming
v SQL programming
v XA APIs
v Journal management
120
IBM i: Database Controllo del commit
(3174 KB)
(5836 KB)
Riferimenti correlati
“File PDF per il controllo del commit” a pagina 1
È possibile visualizzare e stampare un file PDF che contiene le presenti informazioni.
Informazioni sull'esonero di responsabilità e licenza del codice
IBM fornisce una licenza non esclusiva per utilizzare tutti gli esempi del codice di programmazione da
cui creare funzioni simili personalizzate, in base a richieste specifiche.
OLTRE ALLE GARANZIE STABILITE DALLA LEGGE CHE NON POSSONO ESSERE ESCLUSE, IBM,
GLI SVILUPPATORI DEL PROGRAMMA E I FORNITORI NON OFFRONO GARANZIE O CONDIZIONI
ESPRESSE O IMPLICITE, INCLUSO, MA NON SOLO, LE GARANZIE O CONDIZIONI IMPLICITE DI
COMMERCIABILITA', ADATTABILITA' A UNO SCOPO PARTICOLARE E NON CONTRAFFAZIONE
RELATIVAMENTE AL PROGRAMMA E AL SUPPORTO TECNICO, SE PRESENTE.
IN NESSUN CASO IBM, GLI SVILUPPATORI DEL PROGRAMMA O I FORNITORI SARANNO
RESPONSABILI PER QUANTO SEGUE, ANCHE SE INFORMATI DEL POSSIBILE VERIFICARSI DI
TALI DANNI:
1. PERDITA O DANNEGGIAMENTO DI DATI;
2. DANNI PARTICOLARI, INCIDENTALI, DIRETTI O INDIRETTI O QUALSIASI DANNO
ECONOMICO CONSEGUENTE; OPPURE
3. PERDITE DI PROFITTI, AFFARI, ENTRATE O SPESE ANTICIPATE.
LA LEGISLAZIONE DI ALCUNI PAESI NON CONSENTE L'ESCLUSIONE O LA LIMITAZIONE DELLE
GARANZIE DI DANNI DIRETTI, INCIDENTALI O CONSEQUENZIALI, PERTANTO ALCUNE O
TUTTE LE SUDDETTE ESCLUSIONI O LIMITAZIONI POTREBBERO NON ESSERE APPLICABILI.
Controllo del commit
121
122
IBM i: Database Controllo del commit
Appendice. Informazioni particolari
Queste informazioni sono state sviluppate per prodotti e servizi offerti negli Stati Uniti.
IBM può non offrire i prodotti, i servizi o le funzioni presentati in questo documento in altri paesi.
Contattare il rappresentante IBM locale per informazioni sui prodotti e servizi correntemente disponibili
nella propria area. Qualsiasi riferimento ad un prodotto, programma o servizio IBM non implica o
intende dichiarare che solo quel prodotto, programma o servizio IBM può essere utilizzato. Qualsiasi
prodotto funzionalmente equivalente al prodotto, programma o servizio che non violi alcun diritto di
proprietà intellettuale IBM può essere utilizzato. Tuttavia la valutazione e la verifica dell'uso di prodotti o
servizi non IBM ricadono esclusivamente sotto la responsabilità dell'utente.
IBM può avere brevetti o domande di brevetto in corso relativi a quanto trattato nel presente documento.
La fornitura di questa pubblicazione non garantisce la concessione di alcuna licenza su tali brevetti. Chi
desiderasse ricevere informazioni relative alla licenza può rivolgersi per iscritto a:
IBM Director of Commercial Relations
IBM Europe
Schoenaicher Str. 220
D-7030 Boeblingen
Deutschland
Per informazioni sulle richieste di licenze relative al doppio byte (DBCS), contattare il reparto proprietà
intellettuale IBM nel proprio paese o inviare le richieste per iscritto all'indirizzo:
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan, Ltd.
3-2-12, Roppongi, Minato-ku, Tokyo 106-8711, Japan
Le disposizioni contenute nel seguente paragrafo non si applicano al Regno Unito o ad altri paesi nei
quali tali disposizioni non siano congruenti con le leggi locali: IBM FORNISCE QUESTA
PUBBLICAZIONE “COSÌ COM'È” SENZA ALCUNA GARANZIA, ESPLICITA O IMPLICITA, IVI
INCLUSE EVENTUALI GARANZIE DI COMMERCIABILITÀ ED IDONEITÀ AD UNO SCOPO
PARTICOLARE. Alcuni stati non consentono la rinuncia ad alcune garanzie espresse o implicite in
determinate transazioni, pertanto, la presente dichiarazione può non essere applicabile.
Queste informazioni potrebbero contenere imprecisioni tecniche o errori tipografici. Si effettuano
periodicamente modifiche alle informazioni qui accluse; queste modifiche saranno inserite in nuove
edizioni della pubblicazione. IBM si riserva di apportare senza preavviso e in qualsiasi momento
miglioramenti e/o modifiche al/i prodotto/i e/o al/i programma/i descritto/i in questa pubblicazione.
Qualsiasi riferimento a siti web non IBM, contenuto in queste informazioni, viene fornito solo per
comodità e non implica in alcun modo l'approvazione di tali siti. Le informazioni reperibili nei siti Web
non sono parte integrante delle informazioni relative a questo prodotto IBM, pertanto il loro utilizzo
ricade sotto la responsabilità dell'utente.
IBM può utilizzare o distribuire le informazioni fornite in qualsiasi modo ritenga appropriato senza
obblighi verso l'utente.
I licenziatari di questo programma che desiderano avere informazioni allo scopo di abilitare: (i) lo
scambio di informazioni tra i programmi creati indipendentemente e gli altri programmi (incluso il
presente) e (ii) il reciproco utilizzo di informazioni che sono state scambiate, dovrebbero contattare:
IBM Corporation
© Copyright IBM Corp. 2003, 2010
123
Software Interoperability Coordinator, Department YBWA
3605 Highway 52 N
Rochester, MN 55901
U.S.A.
Tali informazioni possono essere disponibili, in base ad appropriate clausole e condizioni, includendo in
alcuni casi, il pagamento di una tassa.
Il programma su licenza descritto in questa pubblicazione e tutto il relativo materiale disponibile viene
fornito da IBM nei termini dell'accordo IBM Customer Agreement, IBM International Program License
Agreement, IBM License Agreement for Machine Code o qualsiasi altro accordo equivalente tra le parti.
Qualsiasi dato sulle prestazioni contenuto in questa pubblicazione è stato stabilito in un ambiente
controllato. Quindi i risultati ottenuti in altri ambienti operativi potrebbero variare in modo significativo.
È possibile che alcune misurazioni siano state effettuate su sistemi a livello di sviluppo e non esiste
alcuna garanzia che tali misurazioni siano le stesse su sistemi generalmente disponibili. Inoltre, è
possibile che alcune misurazioni siano state calcolate tramite estrapolazione. I risultati effettivi possono
variare. Gli utenti di questa pubblicazione devono verificare che i dati siano applicabili al loro specifico
ambiente.
Le informazioni riguardanti prodotti non IBM sono ottenute dai fornitori di tali prodotti, dai loro annunci
pubblicati o da altre fonti pubblicamente reperibili. IBM non ha testato tali prodotti e non può confermare
l'adeguatezza delle prestazioni, della compatibilità o di altre richieste relative a prodotti non IBM. Le
domande sulle capacità dei prodotti non IBM dovranno essere indirizzate ai fornitori di tali prodotti.
Tutte le specifiche relative alle direttive o intenti futuri di IBM sono soggette a modifiche o a revoche
senza notifica e rappresentano soltanto scopi ed obiettivi.
Queste informazioni contengono esempi di dati e prospetti utilizzati in quotidiane operazioni aziendali.
Per illustrarle nel modo più completo possibile, gli esempi includono i nomi di individui, società, marchi
e prodotti. Tutti questi nomi sono fittizi e qualsiasi somiglianza con nomi ed indirizzi utilizzati da gruppi
aziendali realmente esistenti è puramente casuale.
LICENZA DI COPYRIGHT:
Queste informazioni contengono programmi di applicazione di esempio nella lingua di origine, che
illustrano le tecniche di programmazione su varie piattaforme operative. È possibile copiare, modificare e
distribuire questi programmi di esempio in qualsiasi formato senza pagare alcun corrispettivo a IBM, allo
scopo di sviluppare, utilizzare, commercializzare o distribuire i programmi dell'applicazione conformi
all'interfaccia di programmazione dell'applicazione per la piattaforma operativa per cui i programmi di
esempio vengono scritti. Questi esempi non sono stati interamente testati in tutte le condizioni. IBM,
perciò, non fornisce nessun tipo di garanzia o affidabilità implicita, rispetto alla funzionalità o alle
funzioni di questi programmi. I programmi di esempio vengono forniti "COSI' COME SONO", senza
garanzie di alcun tipo. IBM non intende essere responsabile per alcun danno derivante dall'utilizzo dei
programmi di esempio.
Ogni copia, parte di questi programmi di esempio o lavoro derivato, devono includere un avviso sul
copyright, come ad esempio:
© (nome società) (anno). Le parti di questo codice provengono dai Programmi di esempio di IBM Corp.
© Copyright IBM Corp. _immettere l'anno o gli anni_.
Se si sta utilizzando la versione in formato elettronico di questo manuale, le fotografie e le illustrazioni a
colori potrebbero non essere visualizzate.
124
IBM i: Database Controllo del commit
Informazioni sull'interfaccia di programmazione
Questa pubblicazione di controllo del commit illustra le interfacce di programmazione che consentono al
cliente di scrivere programmi per ottenere i servizi di IBM i.
Marchi
IBM, il logo IBM e ibm.com sono marchi di International Business Machines Corp., registrati in molte
giurisdizioni del mondo. Altri nomi di prodotti e servizi possono essere marchi di IBM o di altre società.
Un elenco attuale di marchi IBM è disponibile su Web nella sezione Copyright and trademark
information al sito www.ibm.com/legal/copytrade.shtml.
I seguenti termini sono marchi di IBM Corporation negli Stati Uniti e/o negli altri paesi:
COBOL/400
DB2
Distributed Relational Database Architecture
DRDA
IBM i
IBM
IBM (logo)
Integrated Language Environment
Redbooks
RPG/400
System i
Adobe, il logo Adobe, PostScript® e il logo PostScript sono marchi di Adobe Systems Incorporated negli
Stati Uniti e/o in altri paesi.
UNIX è un marchio registrato di The Open Group negli Stati Uniti e in altri paesi.
Nomi di altre società, prodotti o servizi possono essere marchi o marchi di servizio di altre società.
Termini e condizioni
Le autorizzazioni per l'utilizzo di queste pubblicazioni vengono concesse in base alle seguenti
disposizioni.
Uso personale: È possibile riprodurre queste pubblicazioni per uso personale, non commerciale a
condizione che vengano conservate tutte le indicazioni relative alla proprietà. Non è possibile distribuire,
visualizzare o produrre lavori derivati di tali pubblicazioni o di qualsiasi loro parte senza chiaro consenso
da parte di IBM.
Uso commerciale: È possibile riprodurre, distribuire e visualizzare queste pubblicazioni unicamente
all'interno del proprio gruppo aziendale a condizione che vengano conservate tutte le indicazioni relative
alla proprietà. Non è possibile effettuare lavori derivati di queste pubblicazioni o riprodurre, distribuire o
visualizzare queste pubblicazioni o qualsiasi loro parte al di fuori del proprio gruppo aziendale senza
chiaro consenso da parte di IBM.
Fatto salvo quanto espressamente concesso in questa autorizzazione, non sono concesse altre
autorizzazioni, licenze o diritti, espressi o impliciti, relativi alle pubblicazioni o a qualsiasi informazione,
dato, software o altra proprietà intellettuale qui contenuta.
IBM si riserva il diritto di ritirare le autorizzazioni qui concesse qualora, a propria discrezione, l'utilizzo
di queste pubblicazioni sia a danno dei propri interessi o, come determinato da IBM, qualora non siano
rispettate in modo appropriato le suddette istruzioni.
Appendice. Informazioni particolari
125
Non è possibile scaricare, esportare o ri-esportare queste informazioni se non pienamente conformi con
tutte le leggi e le norme applicabili, incluse le leggi e le norme di esportazione degli Stati Uniti.
IBM NON RILASCIA ALCUNA GARANZIA RELATIVAMENTE AL CONTENUTO DI QUESTE
PUBBLICAZIONI. LE PUBBLICAZIONI SONO FORNITE "COSI' COME SONO", SENZA ALCUN TIPO
DI GARANZIA, ESPRESSA O IMPLICITA, INCLUSE, A TITOLO ESEMPLIFICATIVO, GARANZIE
IMPLICITE DI COMMERCIABILITA' ED IDONEITA' PER UNO SCOPO PARTICOLARE.
126
IBM i: Database Controllo del commit
Stampato in Italia
