Non tutti gli errori nascono uguali. Abbiamo visto cosa sono i permanent error, ma non sono l’ unica forma possibile di errore.

Transient Error

Un problema tipico caratteristica dei sistemi distribuiti è la disponibilità ballerina delle risorse. I sistemi distribuiti mettono in luce molto rapidamente la così dette fallacies of distributed computing, è quindi cosa più che normale che il database, o una risorsa qualsiasi di cui abbiamo bisogno, anche la rete stessa, non sia disponibile nel momento in cui ne abbiamo bisogno.

Sempre tipico dei sistemi distribuiti è che se riproviamo poco dopo tutto fila liscio come ci aspettiamo perché la risorsa in questione è nuovamente disponibile.

Si parla in questo caso di errori transienti, che sono quindi quegli errori che si risolvono da soli “semplicemente” riprovando.

Responsabilità

In questa direzione è interessante notare come il modello di comunicazione scelto modifichi radicalmente responsabilità e conseguenze.

Il modello RPC impone che l’onere del riprovare sia carico del chiamante e qualsivoglia problema il destinatario abbia impatta di conseguenza anche il chiamante. Il modello asincrono basato sui messaggi e code sposta la responsabilità del riprovare sul destinatario, come è giusto che sia per certi versi. Inoltre eventuali problemi del destinatario non impatto diretto sul chiamante.

Ovviamente dobbiamo accettare che il modello di sviluppo sia asincrono e fire & forget.

Adesso che finalmente Ale ha bloggato posso tornare alla mia serie su Services UI Composition, ma prima un ultimo post sulla gestione degli errori di business ;-)