Bestellte Lieferung mit netMSMQbinding

Question

Ist es möglich, eine geordnete Lieferung zu garantieren, wenn Sie WCF netMSMQbinding verwenden?

Wir fügen einen Insert-Befehl ein, gefolgt von einer Anzahl von Update-Befehlen in derselben Warteschlange, und gelegentlich schlägt eine der Aktualisierungen die Einfügung.

Nachdem eine umfangreiche Protokollierung hinzugefügt wurde, ist es klar, dass sie der Warteschlange in der richtigen Reihenfolge hinzugefügt und in einer anderen Reihenfolge verarbeitet werden.

Ich habe Google ein paar Artikel, die behaupten, dass dieses Verhalten erwartet wird, aber es scheint wie es möglich sein muss konfiguriert, um es irgendwie bestellt werden.

Unsere Warteschlangen sind Transaktions-, so dass ich glaube nicht, dass Sequenznummern hinzufügen und Resequenzierung am Ziel arbeiten werde, so dass Transaktionalität

Wenn ich das [DeliveryRequirements(RequireOrderedDelivery=true, QueuedDeliveryRequirements=QueuedDeliveryRequirementsMode.Require)] ich folgende Fehler Attribut hinzufügen würde verlieren bekommen :

Ich habe keine Ahnung, warum wir diesen Fehler bekommen, wie alles "erscheint" um richtig eingerichtet zu werden. Ich habe jedoch keine Bestätigung gefunden, dass diese Einstellung für MSMQ zulässig ist, da es sich um eine WS-RM-Einstellung handelt und AFAIK netMSMQBinding WS-RM nicht unterstützt.

Answer 1

MSMQ unterstützt keine geordnete Zustellung, daher können Sie dies nicht tun.

Werfen Sie einen Blick auf System.ServiceModel.Channels.MsmqBindingElementBase + BindingDeliveryCapabilitiesHelper, die die Klasse MSMQ Bindungsfähigkeiten spezifiziert ist, und wie es implementiert diese Eigenschaft:

bool IBindingDeliveryCapabilities.AssuresOrderedDelivery 
{ 
    get 
    { 
     return false; 
    } 
} 

Answer 2

Sieht aus wie können Sie Gruppennachrichten, Sie so deshalb könnte die Reihenfolge im Vertrag angeben. Überprüfen Sie diese MSDN article on grouping messages.

Answer 3

This post from Simon Gittins sieht aus wie schlägt er vor, bestellten Lieferung möglich:

As it turns out, there's an undocumented feature that deals with this situation:

• Apply a TransactedBatchingBehavior with a batch size of ONE to the service endpoint.
• ReleaseServiceInstanceOnTransactionComplete must be set to true on the service implementation.

Once these two things are done, my test program no longer produces out of order messages.