Transactionele inbox

Een transactionele inbox gebruikt duurzame berichtregistraties om lokale verwerking tegen dubbele afleveringen te beschermen. Bij de hier beschreven variant worden de registratie van een verwerkt bericht en de bijbehorende wijziging in de bedrijfsgegevens in dezelfde databasetransactie opgeslagen.

Een fictieve dienst met consumernaam report-worker ontvangt bericht E-42. Hij schrijft de combinatie van consumer en bericht-ID in zijn inbox en verhoogt een rapportteller van 6 naar 7. Beide wijzigingen worden samen vastgelegd. Een uniciteitsregel in de database voor deze combinatie beschermt ook bij gelijktijdig werkende instanties. Eerst controleren en daarna schrijven is op zichzelf onvoldoende.

Het moment van de crash telt

Mislukt de transactie vóór de commit, dan blijven noch de inboxregistratie noch de tellerwijziging bewaard. Slaagt de commit maar gaat de daaropvolgende bevestiging aan de broker verloren, dan kan E-42 opnieuw aankomen. De bestaande registratie voorkomt dan een verdere verhoging naar 8. De bevestiging aan de broker maakt zelf geen deel uit van deze lokale databasetransactie.

Idempotentie beschrijft het veilige effect van herhaling; een inbox is een mogelijk implementatiepatroon. Een outbox slaat uitgaande berichten samen met de lokale wijziging op. Een inbox alleen garandeert niet dat een externe HTTP-aanroep precies één keer wordt uitgevoerd of een e-mail precies één keer wordt verstuurd. De bewaartermijn van bericht-ID’s moet passen bij de mogelijke periode voor heraflevering en replay; te vroeg verwijderde registraties beschermen niet meer tegen latere duplicaten.

Bronnen

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

• MassTransit: Transactional Outbox and Consumer Inbox