Transacciones distribuidas con WCF

Question

Arquitectura básica: n cajas físicas, cada una de las cuales aloja el mismo servicio WCF, sentadas detrás de un equilibrador de carga. Cada cuadro toca una infraestructura de base de datos única que no admite transacciones; no pregunte :(

Entonces, en la capa de acceso a datos de mi aplicación, necesito algún método de transacciones distribuidas. ¿Cuáles son mis opciones?

Tenga en cuenta que los clientes de mi sistema serán aplicaciones heredadas que se comunicarán mediante servicios web básicos (BasicHttpBinding) y nuevos clientes WCF brillantes (NetTcpBinding o NetNamedPipeBinding).

---

Editar 1

Por ejemplo. habrá una sola llamada a la capa WCF en el cuadro físico 1, p. EditEntity (...). Esta llamada activará 2 escrituras en la base de datos. Después de la primera escritura, otro cliente llama a EditEntity (...) para la misma entidad en una segunda instancia de mi servicio WCF en una segunda casilla física. En el segundo cuadro, ¿cómo sé que una transacción para esta entidad en particular ya está en juego?

Gracias.

Answer 1

¿No está seguro de que nos ha dado lo suficiente para continuar, pero si estoy leyendo correctamente, está intentando asegurarse de que puede respaldar una transacción a través de su servicio WCF? ¿Mientras que su base de datos no admite transacciones y sus puntos finales WCF se encuentran detrás de un equilibrador de carga? ¿Tengo esto correcto? Si es así ...

Dado que su base de datos no tiene soporte transaccional, eso se mueve a su nivel WCF. Esto sugiere un gran nivel de granularidad en sus métodos, de modo que pueda garantizar que una sola llamada a su servicio WCF abarque su transacción lo suficiente. No distribuya una transacción en varias llamadas WCF, está pidiendo problemas.

---

ACTUALIZACIÓN: Existen estrategias que pueden emplearse con equilibradores de carga que aseguran la persistencia entre las conexiones, pero eso no lo ayudará aquí. Si llama a EditEntity () consecutivamente, y la primera entrada es iniciar una transacción, y la segunda entrada es completar una transacción ... entonces su servicio no es lo suficientemente granular.

Consolide esas dos llamadas a un método, es decir, EditEntityComplete ().

¿Hay alguna razón por la que no puede crear un método, en lugar de dos?

---

ACTUALIZACIÓN # 2: Reformulación del problema: un único método realiza entradas dentro de una base de datos que no admite transacciones. El método en cuestión ejecuta una serie de pasos que deben completarse en orden. El método WCF representa oportunidades para la contención de concurrencia para violar la finalización del paso en el orden correcto.

Con esa base, suponiendo que no requiera ningún dato de retorno de la función, considere una cola asíncrona que puede registrar solicitudes de los puntos finales WCF. Luego procese la Cola desde un único proceso en segundo plano.

---

REVISIÓN FINAL:

Reconsidere el requisito de no cambiar el almacén de datos.

Dados los requisitos para múltiples clientes, la necesidad de escala, equilibrio de carga y soporte transaccional en el almacén de datos, una sugerencia final: presionar para cambiar la base de datos. Comprender esto es un requisito estático, pero gastará mucho esfuerzo tratando de implementar el soporte transaccional cuando muchas plataformas de bases de datos simples lo proporcionen. Intentar volver a crear esta funcionalidad tiene pocas ventajas pero muchas desventajas.