Il concetto di idempotenza in informatica è ampiamente abusato e stravolto nel suo significato originale. In matematica l’idempotenza è una caratteristica di una funzione tale che per un dato input X si ha: F(x)=F(F(x)).

In informatica ci si accontenta di definire l’idempotenza come la proprietà di una funzione o di una procedura di produrre lo stesso risultato se invocata N volte consecutivamente con lo stesso input.

Questo è un modo elegante (ma alla lontana) di approcciare i pattern architetturali di Lavoro Asincrono in un contesto Cloud. Immaginiamoci infatti il classico scenario (sotto), in cui un Web Role accumuli delle grandi immagini da elaborare e un Worker Role le voglia processare in modo disconnesso e asincrono.

image

Si vorrà garantire che ogni foto venga processata una e una sola volta, senza produrre effetti collaterali. Vediamo perchè Azure Storage Queue forzi l’utente a cancellare manualmente una entry dalla coda:

  • Un utente sul Web Role carica una immagine
  • L’immagine viene inserita in un blob storage
  • Viene posto un messaggio nella coda con l’URI dell’immagine da elaborare
  • Il Worker role, che nel frattempo “polla” (indicativo presente di Polling) trova il messaggio e lo elabora
  • Purtroppo, a metà elaborazione si ferma e il thread va in crash.

Cosa succede in questo scenario se ci fosse il comune meccanismo di Read-and-Delete? Semplicemente verrebbe perso un dato, senza possibilità di rielaborarlo. Per questo Azure forza l’utente a cancellare il dato una volta completata la computazione; altrimenti il messaggio tornerà visibile dopo 30 secondi (configurabile). Tutto questo purtroppo non basta per garantire idempotenza, visto che può accadere ancora questo scenario:

  • Un utente sul Web Role fa un bonifico
  • I dati vengono inseriti in un coda
  • Il Worker role processa la prima parte di bonifico e addebita 100$ sul conto sorgente, ma poi crasha prima di completare
  • Il messaggio torna disponibile dopo 30 secondi e di nuovo il worker role addebita altri 100$ e stavolta completa l’operazione.
  • Purtroppo così il cliente si trova la somma addebitata due volte.

Per cui è anche necessario, dal punto di vista della logica applicativa, prevedere un meccanismo di compensazione, per processare una richiesta una e una sola volta.