Transazione IT

In informatica , e in particolare in banche dati , una transazione come ad esempio una prenotazione, un acquisto o un pagamento avviene tramite una serie di operazioni che modificano il database da uno stato A - prima della transazione - ad uno stato B più tardi e meccanismi fare è possibile ottenere che questa sequenza sia allo stesso tempo atomica , coerente , isolata e durevole ( ACID ).

La maggior parte dei sistemi di gestione di database gerarchici e relazionali presenti sul mercato consente di effettuare transazioni atomiche, coerenti, isolate e sostenibili. I sistemi NoSQL lo affermano.

Le proprietà ACID

Il concetto di transazione si basa sul concetto di punto di sincronizzazione ( sync point ) che rappresenta uno stato stabile del sistema informatico considerato, in particolare dei suoi dati.

Atomicita Una transazione deve essere fatta in tutto o niente, vale a dire completamente o per niente; Consistenza La coerenza dei dati deve essere garantita in tutti i casi, anche nei casi di errore in cui il sistema deve tornare allo stato di coerenza precedente. La coerenza è stabilita da regole funzionali. Esempio: una transazione immobiliare può richiedere molto tempo. Dal punto di vista informatico, sarà considerata come una procedura funzionale composta da più operazioni informatiche (prenotazione, proposta di acquisto, compromesso, atto notarile). Le fasi intermedie sono quindi gestite funzionalmente tramite lo stato dell'oggetto Appartamento. Anche se la procedura è in corso, tra ogni passaggio il sistema rimane coerente. In caso di abbandono della procedura (una sorta di rollback della transazione immobiliare), le regole funzionali rimettono in vendita l'appartamento. Esistono molti casi procedurali che non possono essere gestiti da una singola transazione IT. Il progettista deve specificare le regole funzionali che controllano i cambiamenti di stato degli oggetti interessati e gestire manualmente l'equivalente di commit e rollback della procedura; Isolamento La transazione funzionerà in modalità isolata dove solo lui potrà vedere i dati che sta modificando, in attesa di un nuovo punto di sincronizzazione; il sistema garantisce altre transazioni, eseguite in parallelo sullo stesso sistema, visibilità sui dati passati. Questo si ottiene grazie ai blocchi di sistema impostati dal DBMS. L'esempio seguente illustra un isolamento più funzionale che implementa un blocco dell'applicazione: Un attore inserisce un ordine in vista di un contesto. Questo contesto non deve essere cambiato quando convalida il suo ordine, altrimenti l'ordine potrebbe perdere tutto il suo significato. Per evitare che il contesto cambi, è possibile bloccarlo prima di leggerlo. Ma è spesso un consumatore di risorse del computer e scomodo per gli altri, soprattutto se la riflessione e l'input durano diversi minuti. In gestione è generalmente sufficiente verificare semplicemente al momento dell'aggiornamento che il contesto non sia cambiato: ottimisticamente l'isolamento viene verificato a posteriori; Durevolezza Quando la transazione è completa, il sistema è in uno stato stabile durevole, dopo una modifica transazionale riuscita o dopo un errore che si traduce in un ritorno allo stato stabile precedente. La sostenibilità è spesso coinvolta nell'elaborazione batch ( batch ) o nella replica asincrona che producono emissioni. L'applicazione a valle non ha il diritto di mettere in discussione la transazione precedente che ha generato l'evento, altrimenti ciò significherebbe che questa transazione non ha lasciato il sistema in uno stato coerente. L'applicazione a monte deve quindi controllare tutto attentamente prima di diffondere l'informazione. Quando l'architettura funzionale non è pura, è spesso necessario gestire i rifiuti. Questi trattamenti eccezionali devono poi essere specificati in modo che gli scarti vengano riciclati con una procedura funzionale spesso complessa. Da qui l'importanza della coerenza dell'operazione rispetto all'intero sistema.

Esempio di transazione nel mondo bancario

Ad esempio, durante un'operazione del computer di trasferimento di denaro da un conto bancario a un altro conto bancario, c'è un'attività di prelevare denaro dal conto di origine e un'attività di deposito dal conto di destinazione. Il programma per computer che esegue questa transazione garantirà che entrambe le operazioni possano essere eseguite senza errori e, in questo caso, la modifica diventerà effettiva su entrambi gli account. In caso contrario l'operazione viene annullata. Entrambi gli account mantengono i valori iniziali. Ciò garantisce la coerenza dei dati tra i due account.

Utilizzare nei database

Le transazioni informatiche sono ampiamente utilizzate nei DBMS.

Nickname transazionale

Questa vecchia tecnica, ampiamente praticato con monitor transazionali quali l'IBM CICS , TDS di Bull, Siemens UTM, è ora ampiamente utilizzato in applicazioni web architetture , e nel client-server applicazioni .

In effetti niente assomiglia di più a una pagina web di uno schermo sincrono:

Il problema posto in questa modalità di funzionamento è che a volte è necessaria una sequenza di più schermate o pagine per sviluppare una transazione ACID completa . È stata la metodologia Merise a definire per la prima volta questi concetti:

Questo compito è assimilato a una pseudo-transazione che, dal punto di vista del monitor, è una transazione tecnica, ma ovviamente non è realmente funzionale fino al termine della sequenza.

Ma :

Domande :

Le risposte degli anziani sono anche quelle usate oggi nelle "nuove" tecnologie:

Comprendiamo perché se impostassimo i blocchi di sistema (SGBD) in tutta la catena la cui durata è incontrollabile, il sistema crollerebbe. Questo è il punto centrale dello pseudo transazionale. Ma la strategia di controllo dell'isolamento è fondamentalmente funzionale.

La pseudo transazione è quindi ACID, ma le regole funzionali sono tali che la coerenza tra ogni pseudo transazione in una sequenza è garantita dall'assenza di aggiornamento del database.


Un'applicazione client / server ben progettata utilizza anche pseudo-transazioni, ma il contesto viene gestito nell'applicazione client, il che alleggerisce il server. Il diagramma tipico è il seguente:

Il che dà N + 1 pseudo-transazioni.

Vedi anche

Note e riferimenti

  1. (a) Philip A. Bernstein e Eric Newcomer, Principles of transaction processing , Morgan Kaufmann - 1997 ( ISBN  9781558604155 )
  2. Peter McIntyre et al., Pro PHP Programming , Apress, pagina 127: “I database NoSQL, come suggerisce il nome, non sono database SQL classici e non implementano le proprietà ACID. "

Bibliografia