Messaggistica transazionale
La base del modello di programmazione di Service Broker è rappresentata dalla messaggistica transazionale. Qualsiasi operazione eseguita in Service Broker fa parte della transazione corrente. Service Broker non esegue il commit di un'operazione di messaggistica fino a quando non viene eseguito il commit della transazione corrente. Se viene eseguito il rollback della transazione, il Motore di database garantisce che venga eseguito il rollback anche di tutte le operazioni di messaggistica che fanno parte della transazione. La gestione delle operazioni di messaggistica in un'applicazione fa parte della gestione della transazioni di SQL Server.
Quando ad esempio un programma invia un messaggio all'interno di una transazione, Service Broker non invia il messaggio sulla rete fino a quando il programma non ha eseguito il commit della transazione. Quando un programma riceve un messaggio all'interno di una transazione, il Motore di database non rimuove il messaggio dalla coda in modo permanente fino a quando il programma non ha eseguito il commit della transazione.
La messaggistica transazionale consente di scrivere applicazioni affidabili e scalabili garantendo che lo stato del database rimanga coerente con lo stato delle code. Quando un'applicazione apporta una modifica al database e invia o riceve un messaggio, la modifica al database e l'operazione di messaggistica fanno parte della stessa transazione. Se viene eseguito il rollback della transazione, viene eseguito il rollback sia della modifica al database che dell'operazione di messaggistica, in modo che entrambe le operazioni abbiano esito positivo o che entrambe abbiano esito negativo. Nel modello di Service Broker un'applicazione utilizza la messaggistica transazionale per garantire che i messaggi inviati dall'applicazione riflettano lo stato corrente del database.
Per sfruttare tutti i vantaggi della messaggistica transazionale, scrivere le applicazioni in modo che le operazioni di messaggistica si verifichino nella stessa transazione delle operazioni del database rappresentate dai messaggi. Un'applicazione che elabora un ordine ad esempio riceve il messaggio relativo e aggiorna il database in base all'ordine in una sola transazione.
Se l'applicazione riceve invece il messaggio in una transazione e aggiorna il database in una transazione diversa, l'impossibilità di aggiornare il database determina una situazione per cui il messaggio non esiste più, ma la modifica richiesta dal messaggio non è stata apportata. In questo caso, l'applicazione non sfrutta uno dei vantaggi principali di Service Broker. In particolare, Service Broker garantisce che tutti i messaggi vengano recapitati esattamente una volta e nell'ordine corretto. In caso contrario, il mittente del messaggio riceve una notifica con un messaggio di errore di Service Broker. Un'applicazione che rimuove in modo permanente un messaggio dalla coda, ma non riesce a elaborare il messaggio, come descritto in questo esempio, viola questa condizione senza la quale l'applicazione deve contenere codice aggiuntivo per gestire le possibili incoerenze o il rischio che si verifichino risultati non corretti.
Quando un'applicazione elabora un messaggio e non apporta modifiche al database, la condizione viene rispettata poiché il messaggio è stato elaborato correttamente. Un'applicazione che utilizza Service Broker può scegliere di ignorare un messaggio, ma l'applicazione non deve perdere inavvertitamente un messaggio, anche nei casi in cui l'applicazione perda la connettività al database o venga chiusa in modo imprevisto.
Vedere anche