WCF basicHttpBinding: Cofnij, gdy odpowiedź na klienta się nie powiedzie

Question

Ujawniam usługę WCF za pośrednictwem basicHttpBinding, która wykonuje kilka operacji w bazie danych.

Chcę zagwarantować, że jeśli klient nie otrzyma odpowiedzi operacje bazy danych zostaną wycofane (bez przepływu transakcji przez WCF). E.g. klient wywołuje metodę "DoX", która jest wykonywana na serwerze, ale przed jej zakończeniem następuje zawieszenie klienta. Operacje bazy danych powinny zostać wycofane, gdy tylko odpowiedź nie zostanie wysłana do klienta.

Czy jest jakiś sposób to zrobić? Czy atrybut [OperationBehavior(TransactionScopeRequired=true)] działa w taki sposób? Czy istnieje możliwość poradzenia sobie z błędami komunikacji po stronie serwera?

Aktualizacja 1: Wydaje [OperationBehavior(TransactionScopeRequired=true)] zatwierdza transakcję przed odpowiedź jest wysyłany do klienta, a tym samym nie może być stosowany do wykonywania wycofywania jeśli klient nie otrzyma odpowiedzi.

Aktualizacja 2: Aby stwierdzić jasno znowu, nie mam potrzeby transakcji oddziaływać w żaden sposób ze strony klienta. Klient nie powinien znać transakcji, mieć możliwości jej anulowania ani zatwierdzenia, a transakcja nie powinna przepływać przez powiązanie. Tylko miejsce, w którym chcę, aby transakcja została wycofana, znajduje się po stronie serwera, jeśli kanał transportu nie może dostarczyć wiadomości do klienta odbierającego. W przypadku TCP/IP informacje te powinny być łatwo dostępne dla serwera. (Brak ACK pakietu TCP wysłać do klienta)

Więc hipotetyczny przepływ wykonanie po stronie serwera (zauważyć brak po stronie klienta) powinno być:

Receive client request 

Start transaction 

Execute all logic inside the service operation 

Send reply back to client 

if (reply.failedToReceive) { transaction.Rollback() } // due to a failing TCP/IP transmission 

Answer 1

Nie ma prostej odpowiedzi to pytanie. Pytasz o zachowanie, które zostało zaimplementowane w WS- *, ale zostało zrobione przy użyciu podstawowego SOAP. Myślę, że jedyną opcją, jeśli NAPRAWDĘ nie możesz przełączyć się na wsHttpBinding lub użyć dupleksu zgodnie z sugestią @Trevor Pilley, jest próba naśladowania zachowania transakcji WS w swoim własnym niestandardowym protokole opartym na podstawowym SOAP.

powinny być w stanie uzyskać pewne uproszczenie nad pełną specyfikacją WS-Transaction ponieważ

• Będziesz prawdopodobnie tylko potrzebne do obsługi transakcji w ramach jednej usługi - nie będzie robić transakcji rozproszonej na kilku niezależnych usługi
• nie trzeba będzie wspierać zarówno krótkim transakcje (WS-AtomicTransaction), jak również transakcji z długim terminem biegania (WS-BusinessActivity) probaby transakcje atomowe zrobi
• nie musiałby obsługiwać każdy rodzaj modelu rozciągliwości (WS-Coordination)
• Nie trzeba implementować modelu wykrywania/metadanych opisującego protokół (np. jak WSDL), ponieważ kodowałbyś zachowanie protokołu bezpośrednio do klienta i usługi.

Prawdopodobnie potrzebne byłyby jednak elementy zarówno WS-Coordination, jak i WS-AtomicTransaction.Nie jest to proste zadanie i łatwo będzie przeoczyć coś subtelnego, co może spowodować, że albo wycofanie się nie nastąpi, albo (tak samo źle), aby zniszczyć wydajność usługi przez długi czas blokowania całej bazy danych z powodu rozbił klientów.

Tak jak mówię, jest to złożone zachowanie i jeśli nie można używać gotowych, standardowych protokołów, nie ma prostej odpowiedzi.