WCF basicHttpBinding: revertir cuando falla la respuesta al cliente

transactions

Question

Estoy exponiendo un servicio WCF a través de un basicHttpBinding que ejecuta varias operaciones en una base de datos.

Quiero garantizar que si el cliente no recibe la respuesta, las operaciones de la base de datos se revierten ( sin ningún flujo de transacción a través de WCF ). Por ejemplo, el cliente llama al método "DoX" que se ejecuta en el servidor pero antes de que finalice, el cliente se bloquea. Las operaciones de la base de datos se deben revertir tan pronto como la respuesta no se pueda enviar al cliente.

¿Hay alguna forma de hacer eso? ¿ [OperationBehavior(TransactionScopeRequired=true)] atributo [OperationBehavior(TransactionScopeRequired=true)] de tal manera? ¿Existe la posibilidad de manejar errores de comunicación en el lado del servidor?

Actualización 1: Parece que [OperationBehavior(TransactionScopeRequired=true)] confirma la transacción antes de enviar la respuesta al cliente y, por lo tanto, no se puede usar para realizar una reversión si el cliente no recibe la respuesta.

Actualización 2: Para volver a expresarlo claramente, no tengo la necesidad de que la transacción interactúe de ninguna manera con el lado del cliente. El cliente no debe saber de la transacción, tener la capacidad de cancelarla o comprometerla, ni debe fluir ninguna transacción a través del enlace. El único lugar donde quiero que se retrotraiga la transacción está en el lado del servidor si el canal de transporte no puede entregar el mensaje al cliente receptor. Con el caso de TCP / IP, esta información debería estar disponible para el servidor. (No se devuelve ningún ACK del paquete TCP al cliente)

Entonces, un flujo hipotético de ejecución en el lado del servidor (observe la falta de lado del cliente) debería ser:

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

No hay respuesta fácil para esta pregunta. Está solicitando un comportamiento que se implementa en WS- * pero que se realiza con SOAP básico. Creo que su única opción si REALMENTE no puede cambiar a wsHttpBinding o usar dúplex como lo sugiere @Trevor Pilley es tratar de imitar el comportamiento de WS-Transaction en su propio protocolo personalizado basado en SOAP básico.

Debería poder obtener alguna simplificación sobre la especificación WS-Transaction completa porque

• Probablemente solo necesite admitir transacciones en un solo servicio: no realizará una transacción distribuida en varios servicios independientes.
• No será necesario admitir tanto las transacciones cortas ( WS-AtomicTransaction ) como las transacciones de larga duración ( WS-BusinessActivity ) probaby
• No es necesario que admita ningún tipo de modelo de extensibilidad ( WS-Coordination )
• No necesitaría implementar un modelo de descubrimiento / metadatos que describa el protocolo (p. Ej., Como WSDL) porque estaría codificando el comportamiento del protocolo directamente en el cliente y el servicio.

Sin embargo, es probable que necesite elementos de WS-Coordination y WS-AtomicTransaction. Esta no es una tarea sencilla de ninguna manera y será fácil perder algo sutil que podría causar que no se realicen retrocesos o (igual de malo) destruir el rendimiento de su servicio al tener bloqueos de larga duración en toda su base de datos debido a clientes bloqueados

Como dije, este es un comportamiento complejo y si no puede usar protocolos estandarizados ya preparados, no hay una respuesta simple.