Transactional inbox

Una transactional inbox usa registrazioni durature dei messaggi per proteggere l’elaborazione locale dalle consegne duplicate. Nella variante qui descritta, la registrazione del messaggio elaborato e la relativa modifica ai dati applicativi vengono salvate nella stessa transazione del database.

Un servizio fittizio con nome consumer report-worker riceve il messaggio E-42. Inserisce nella propria inbox la combinazione di consumer e identificativo del messaggio e aumenta un contatore di report da 6 a 7. Le due modifiche vengono confermate insieme. Un vincolo di unicità nel database su questa combinazione protegge anche in presenza di istanze che lavorano contemporaneamente. Controllare prima e scrivere dopo non basta da solo.

Conta il momento dell’arresto

Se la transazione fallisce prima del commit, non persistono né la registrazione nell’inbox né la modifica al contatore. Se il commit riesce ma va persa la successiva conferma al broker, E-42 può arrivare di nuovo. La registrazione esistente impedisce allora un ulteriore incremento a 8. La conferma al broker non fa parte di questa transazione locale del database.

L’idempotenza descrive l’effetto sicuro di una ripetizione; l’inbox è un possibile schema per ottenerlo. Un’outbox salva invece i messaggi in uscita insieme alla modifica locale. L’inbox da sola non garantisce che una chiamata HTTP esterna venga eseguita o un’e-mail venga inviata esattamente una volta. La conservazione degli identificativi deve coprire il possibile periodo di riconsegna e replay; le registrazioni rimosse troppo presto non proteggono più dai duplicati successivi.

Fonti

• Chris Richardson: Handling duplicate messages using the Idempotent consumer pattern

• MassTransit: Transactional Outbox and Consumer Inbox