WCF basicHttpBinding: откат при сбое ответа клиенту

Question

Я предоставляю сервис WCF через basicHttpBinding, который выполняет несколько операций с базой данных.

Я хочу гарантировать, что если клиент не получит ответ, операции базы данных будут отменены ( без какого-либо потока транзакций через WCF ). Например. клиент вызывает метод «DoX», который выполняется на сервере, но до его завершения клиент падает. Операции с базой данных следует откатить, как только ответ не может быть отправлен клиенту.

Есть ли способ сделать это? Будет ли атрибут [OperationBehavior(TransactionScopeRequired=true)] работать таким образом? Есть ли возможность обрабатывать ошибки связи на стороне сервера?

Обновление 1: Кажется, [OperationBehavior(TransactionScopeRequired=true)] фиксирует транзакцию до того, как ответ будет отправлен клиенту, и поэтому не может быть использован для отката, если клиент не получил ответ.

Обновление 2: Чтобы еще раз четко заявить, у меня нет необходимости каким-либо образом взаимодействовать с клиентской стороной. Клиент не должен знать о транзакции, иметь возможность отменить или зафиксировать ее, и никакая транзакция не должна проходить через привязку. Место только , для которого я хочу выполнить откат транзакции, находится на стороне сервера, если транспортный канал не может доставить сообщение получающему клиенту. В случае TCP / IP эта информация должна быть легко доступна для сервера. (ACK пакета TCP не отправляется обратно клиенту)

Таким образом, гипотетический поток выполнения на стороне сервера (обратите внимание на отсутствие на стороне клиента) должен быть:

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

Нет простого ответа на этот вопрос.Вы запрашиваете поведение, которое реализовано в WS- *, но выполняется с использованием базового SOAP.Я думаю, что ваш единственный вариант, если вы ДЕЙСТВИТЕЛЬНО не можете переключиться на wsHttpBinding или использовать дуплекс, как предложено @Trevor Pilley, это попытаться имитировать поведение WS-Transaction в вашем собственном настраиваемом протоколе на основе базового SOAP.

Вы должны быть в состоянии упростить всю спецификацию WS-Transaction, поскольку

• Вам, вероятно, потребуется поддерживать транзакции только для одного сервиса - вы не будете выполнять распределенную транзакцию для нескольких независимых сервисов.
• Вам не нужно будет поддерживать как короткие транзакции ( WS-AtomicTransaction ), так и долгосрочные транзакции ( WS-BusinessActivity ), которые будут выполнять вероятные атомарные транзакции
• Вам не нужно будет поддерживать какую-либо модель расширяемости ( WS-Coordination )
• Вам не нужно будет реализовывать модель обнаружения / метаданных, которая описывает протокол (например,как WSDL), потому что вы будете кодировать поведение протокола непосредственно вent и service.

Однако вам, вероятно, потребуются элементы как WS-Coordination, так и WS-AtomicTransaction.Это непростая задача, во всяком случае, и будет легко пропустить что-то тонкое, что может привести к тому, что откаты не произойдут или (столь же плохо) повредят производительность вашего сервиса, имея длительные блокировки по всей вашей базе данных из-зааварийные клиенты.

Как я уже сказал, это сложное поведение, и если вы не можете использовать готовые стандартизированные протоколы, простого ответа не существует.