Er det noe form for "lås" på Kvitteringer man leser fra Kvitteringskøen

[ArneHB]

Er det noen form for "lås" på Kvitteringer man leser fra Kvitteringskøen, før man bekrefter den? Jeg lurer på hvor godt det støtter å ha flere tråder som leser fra Kvitteringskøen, eller om man da vil risiker å lese samme kvitteringer på to forskjellige tråder.

[johnksv]

Kvitteringer blir liggende på kvitteringskøen i meldingsformidleren frem til de bekreftes. Hvis du har flere tråder som utfører kall mot hentKvittering gir altså disse samme resultat frem til kvitteringen bekreftes. Fra javadoc-en til bekreft-metoden:

hentKvittering(KvitteringForespoersel) kommer ikke til å returnere en ny kvittering før mottak av den forrige er bekreftet

Hvis man ønsker flere køer kan det opprettes ved å spesifisere mpcId på forsendelsen, og deretter på KvitteringForespoersel for å hente kvitteringer fra denne køen.

[ArneHB]

Supert takk @johnksv ! Siste spørsmål, hvilken meldingsid er det ReferanseTilMeldingId referer til, og hvordan/hva er det tiltenkt at ReferanseTilMeldingId skal brukes til? Jeg fant ikke dette i dokumentasjonen i Java eller Dotnet

[johnksv]

Jeg mener at ReferanseTilMeldingId er ID-en til den forrige EBMS-meldingen. Altså ikke noe konsumenten av dette biblioteket har noe forhold til. Jeg synes sånn sett det virker rart at det eksponeres ut av API-et. Mulig det har sine grunner og use-cases som jeg ikke er klar over.

Eksempel: Avsender sender til meldingsformidler(MF), med EBMS-protokoll. Denne har en meldingsID. MF svarer med en EBMS i retur. Denne har en annen meldingsID, samt et referanseTilMeldingID-felt som er lik den forrige meldingensID.

[ArneHB]

Aha skjønner, takk for svar! Da lukker jeg denne 👍