...
- Uppdateringar som lagts på kö skrivs till databasen (som nyupplägg eller uppdatering, en så kallad "upsert") samt publiceras läggs på en topic kö för distribution till prenumeranter.
- Bearbetningen utförs under kontroll av en transaktion och med en retry policy i köhanteraren som vi fel backar ändringen, loggar felet samt startar om bearbetningen efter en tidsperiod.
- Tidsperioden för nya försök ökar med antalet omförsök för ett visst meddelande så att ett tillfälligt fel inte fördröjer en uppdatering onödigt länge men ett varigt fel å andra sidan inte medför en hög belastning på systemet drivet av täta omförsök som kontinuerligt misslyckas.
- Då bearbetningen använder sig av såväl en köhanterare samt en databas så använder man normalt sett en global XA transaktion för att garantera transaktionell konsistens i bearbetningen.
För att dels slippa den prestandamässiga overheaden i en XA transaktion samt dess baksida med en inte helt oproblematisk hantering (recovery) av mer komplicerade felfall så kommer databasuppdateringen skötas av en lokal databastransaktion och köhanteringen (läs från kö och skriv till topickö) i en separat kö-transaktion. Databasens transaktion kommer committas först vilket leder till att ett eventuellt fel under den mycket korta tiden mellan databas-committen och kö-committen så kommer databasen vara uppdaterad men meddelandet kommer läggas tillbaka på in-kön och inga prenumeranter kommer notifieras via topicenkön. Vid nästa lyckade omförsök kommer prenumeranter notifieras och meddelandet tas bort från in-kön. Databas-uppdateringen är idempotent, dvs kan göras om många gånger utan att resultatet av uppdateringen ändras, dvs informationen blir inte felaktig i databasen pga upprepade uppdateringar baserat på samma meddelande på kön. - Innan meddelanden läggs på en kö för distribution till prenumeranter finns det två villkor som plockar bort poster ur ett meddelande till en viss prenumerant. Det första villkoret kontrollerar om en post ej har förändrats mot den lagrade informationen i databasen, dvs om ingen förändring skett skall inte posten skickas vidare ut till en prenumerant. Det andra villkoret kontrollerar om en prenumerant har filter satta (anger vilka tjänstedomäner prenumeranten är intresserad av). Om filter finns och posten ej tillhör en tjänstedomän som prenumeranten vill få notifieringar om plockas posten bort.
Prenumerant tar emot förändringar från ett engagemangsindex
...