Transactional Inbox

Eine Transactional Inbox nutzt dauerhafte Nachrichteneinträge, um die lokale Verarbeitung gegen doppelte Zustellungen abzusichern. Bei der hier beschriebenen Variante werden die Kennzeichnung einer verarbeiteten Nachricht und ihre fachliche Datenbankänderung in derselben Transaktion gespeichert.

Ein fiktiver Dienst mit dem Verbrauchernamen report-worker erhält die Nachricht E-42. Er trägt die Kombination aus Verbraucher und Nachrichten-ID in seine Inbox ein und erhöht einen Berichtszähler von 6 auf 7. Beide Änderungen werden gemeinsam festgeschrieben. Eine Eindeutigkeitsbedingung in der Datenbank für diese Kombination schützt auch bei gleichzeitig arbeitenden Instanzen. Nur vorher nachzusehen und anschließend zu schreiben reicht dafür nicht.

Der Absturzzeitpunkt entscheidet

Scheitert die Transaktion vor dem Commit, bleiben weder der Eintrag noch die Zähleränderung bestehen. Ist der Commit erfolgt, aber die anschließende Broker-Bestätigung geht verloren, kann E-42 erneut eintreffen. Der vorhandene Eintrag verhindert dann eine weitere Erhöhung auf 8. Die Bestätigung an den Broker ist selbst kein Teil dieser lokalen Datenbanktransaktion.

Idempotenz bezeichnet die sichere Wirkung einer Wiederholung; die Inbox ist ein mögliches Umsetzungsmuster. Eine Outbox speichert dagegen ausgehende Nachrichten zusammen mit der lokalen Änderung. Die Inbox garantiert für externe HTTP-Aufrufe oder den Versand von E-Mails nicht automatisch eine genau einmalige Ausführung. Die Aufbewahrung der Nachrichten-IDs muss zum möglichen Wiederholungs- und Replay-Zeitraum passen; zu früh entfernte Einträge verlieren ihren Schutz vor späteren Duplikaten.

Quellen

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

• MassTransit: Transactional Outbox and Consumer Inbox