Transaction processing: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Bot: Aggiungo: ru:Обработка транзакций |
m disambigua, typos |
||
Riga 9:
Si consideri l'ipotesi di un signore che intende trasferire [[€]]100,00 dal proprio [[conto corrente]] verso un altro. Questa transazione è una singola operazione secondo la [[banca]], ma coinvolge almeno due funzionamenti separati in termini di elaborazione informatica: addebitamento del cliente per i cento euro ipotizzati ed accredito della stessa cifra per il destinatario del bonifico effettuato.
Se l'addebito si conclude con successo ma non l'accredito (o viceversa), ci sarebbe un errore in uno dei due [[Sistema (informatica)|sistemi informatici]] delle banche coinvolte. È dunque necessario accertarsi che entrambi i [[processo|processi]] riescano oppure che entrambi vengono a mancare, di modo che non vi sia mai alcuna contraddizione nella base dati della banca o delle banche coinvolte.
La strutturazione teorica del ''transaction processing'' è destinata a fornire la garanzia di coerenza rispetto alle elaborazioni di questo genere; i diversi funzionamenti di ciascuna parte della elaborazione, legata ad una [[Funzione (informatica)|funzione]], sono collegati insieme automaticamente come singola transazione indivisibile.
Il sistema d'elaborazione si accerta che tutti i singoli processi in una transazione siano completati senza errore, altrimenti nessuno di loro risulterà completato. Se alcuni processi sono stati infatti completati ma anche uno di essi risulta errato, vi sarà un'operazione di ''[[rollback]]'' completo per tutti i processi, compresi quelli che erano stati completati con successo, e la transazione risulterà non eseguita. Lo stato del sistema viene ricondotto allo ''stato noto'' precedente, senza memoria delle operazioni tentate o completate all'interno della transazione stessa.
Diversamente, se tutte le operazioni previste per una transazione sono completate con successo, la transazione si definisce "''committed''" e lo ''stato del sistema'' passa a quello successivo. Tutti i cambiamenti delle basi dati coinvolte vengono resi permanenti (definitivi) e non è ora possibile operare ''rollback'' del sistema.
Riga 43:
[[Categoria:Terminologia informatica]]
[[Categoria:Teorie su base dati]]
[[Categoria:Ingegneria del software]]
|