Zamówiona dostawa z NetMSMQbinding

Question

Czy można zagwarantować dostawę zamówioną przy użyciu usługi WCMS netMSMQbinding?

Jesteśmy wprowadzenie polecenia insert a następnie przez szereg poleceń aktualizacji w tej samej kolejce, a od czasu do czasu jeden z aktualizacji bije wkładkę.

Po dodaniu dużej ilości rejestrowanie jasne jest, że są one umieszczone w kolejce w odpowiedniej kolejności i przetwarzania w innej kolejności.

udało mi się Google kilka artykułów, które stwierdzają, że oczekuje tego zachowania, ale wydaje się, że to musi być możliwość skonfigurowania go zamawiać jakoś.

Nasze kolejki są transakcyjna, więc nie sądzę, że dodając kolejne numery i resequencing w miejscu przeznaczenia będzie działać, jako że tracą transakcyjności

Jeśli dodać atrybut [DeliveryRequirements(RequireOrderedDelivery=true, QueuedDeliveryRequirements=QueuedDeliveryRequirementsMode.Require)] pojawia się następujący błąd :

The DeliveryRequirementsAttribute on contract 'IService' specifies a QueuedDeliveryRequirements value of NotAllowed. However, the configured binding for this contract specifies that it does support queued delivery. A queued binding may not be used with this contract.

Nie mam pojęcia, dlaczego otrzymujemy ten błąd, ponieważ wszystko "wydaje się" poprawnie ustawione. Nie udało mi się znaleźć żadnego potwierdzenia, że ​​to ustawienie jest dozwolone dla MSMQ, ponieważ wydaje się, że jest to ustawienie WS-RM, a AFAIK netMSMQBinding nie obsługuje WS-RM.

Answer 1

MSMQ nie obsługuje zamówił dostawę, stąd nie można.

Spójrz na System.ServiceModel.Channels.MsmqBindingElementBase + BindingDeliveryCapabilitiesHelper który jest klasą określania zdolności wiązania Msmq, a jak to realizuje tę właściwość:

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

Answer 2

wygląda można wiadomości grupowe, więc dlatego może określić zamówienie w umowie. Sprawdź to MSDN article on grouping messages.

Answer 3

This post from Simon Gittins wygląda to sugeruje, że zamówił dostawa jest możliwa:

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.