Transaktionel inbox
En transaktionel inbox bruger varige meddelelsesregistreringer til at beskytte lokal behandling mod dobbelte leveringer.
En transaktionel inbox bruger varige meddelelsesregistreringer til at beskytte lokal behandling mod dobbelte leveringer. I den variant, der beskrives her, gemmes registreringen af en behandlet meddelelse og dens forretningsmæssige dataændring i samme databasetransaktion.
En fiktiv tjeneste med forbrugernavnet report-worker modtager meddelelsen E-42. Den registrerer kombinationen af forbruger og meddelelses-ID i sin inbox og øger en rapporttæller fra 6 til 7. Begge ændringer committes samlet. En unikhedsbegrænsning i databasen for denne kombination beskytter også ved samtidige instanser. At kontrollere først og skrive bagefter er ikke tilstrækkeligt i sig selv.
Tidspunktet for nedbruddet betyder noget
Fejler transaktionen før commit, bliver hverken inboxregistreringen eller tællerændringen gemt varigt. Lykkes commit, men den efterfølgende kvittering til brokeren går tabt, kan E-42 komme igen. Den eksisterende registrering forhindrer så en yderligere stigning til 8. Kvitteringen til brokeren er ikke selv en del af denne lokale databasetransaktion.
Idempotens beskriver den sikre virkning af gentagelse; en inbox er et muligt implementeringsmønster. En outbox gemmer derimod udgående meddelelser sammen med den lokale ændring. Inboxen alene garanterer ikke, at et eksternt HTTP-kald udføres eller en e-mail sendes præcis én gang. Opbevaringen af meddelelses-ID’er skal passe til det mulige tidsrum for genlevering og replay; registreringer, der fjernes for tidligt, beskytter ikke længere mod senere dubletter.
Kilder
Relaterede begreber
- IdempotensEn idempotent handling har samme tilsigtede virkning på tilstanden ved identisk gentagelse som ved én udførelse.
- MeddelelseskvitteringEn meddelelseskvittering fortæller brokeren, at en levering er modtaget eller behandlet efter den aftalte regel.
- Jitter ved genforsøgRetry-jitter varierer ventetider tilfældigt for at sprede genforsøg og mindske samtidige forespørgsler fra mange klienter.
- TestkundemiljøEt logisk afgrænset kundeområde i en multitenant-applikation, indrettet til kontroller.
- Genafsendelse af webhookGenafsendelse af webhook sender en meddelelse igen. Bevidst genopretning og replay-angreb kræver forskellige kontroller.
- IdempotensnøgleEn idempotensnøgle identificerer gentagelser af den samme tilsigtede anmodning. Område, opbevaring og API-regler bestemmer dens virkning.
Artikler om emnet
Snitflader & integration med ASES
ERP, CRM og webshop forbundet ordentligt