¿Cómo sabe una SQLCachedependency cuándo comunicarse a cualquier oyente cuando los datos en una tabla cambian?

Question

He estado investigando un poco y puedo ver la mayoría de las tuberías para este sistema, sin embargo, no estoy seguro de cómo SQL Server sabe cuándo disparar un mensaje a cualquier oyente (aplicaciones) cuando los datos en una tabla cambian, por ejemplo. Comenzaré explicando lo que entiendo hasta el punto de que me estoy perdiendo.

1) El corredor de servicio debe habilitarse en la base de datos y se deben establecer algunos permisos.

2) El esquema de la base de datos debe implementarse.

3) Usando ASPNET_REGSQL.EXE, habilite la dependencia de caché de SQL para la base de datos y las tablas para las que necesita almacenar datos (este paso crea una tabla para rastrear los cambios y desencadenar en las tablas para capturar cambios e incrementar un valor en esa tabla).

4) Configure la dependencia de caché SQL en la aplicación .NET. Por ejemplo, en una aplicación web, deberá agregar valores de configuración para el tiempo de encuesta, la cadena de conexión, etc. Inicie/detenga la dependencia en su global.asax.cs y luego agregue dependencias de caché SQL cuando agregue elementos a su caché.

4a) Parte de lo que sucede al comenzar la dependencia es que la infraestructura está configurada para una cola, un servicio y un SPROC para la comunicación y la limpieza después. Usando el Profiler de consulta SQL, puede ver que se realiza la conexión y se está configurando un canal de comunicación en el servicio para que la aplicación reciba mensajes de SQL Server.

5) Aquí es donde me confunde. En este punto, he almacenado en caché un elemento en mi caché de aplicación con una referencia a la dependencia de la caché SQL en la tabla subyacente para que mi aplicación pueda recibir cambios en el caso de que los cambios de fila. Si ejecuto manualmente una actualización en esa fila, puedo ver que el disparador se alcanza y el valor en la tabla de seguimiento se incrementa con 1. Sin embargo, no veo que ninguna comunicación vuelva a la aplicación, nada en el perfilador de consulta SQL, ni ¿El elemento se elimina del caché? Tampoco veo nada en las colas en la base de datos (ni la cola de aplicación dinámica ni las colas de error/transmisión estándar)

Mi pregunta es, ¿qué está viendo esa tabla de seguimiento en la base de datos para que los mensajes se puedan enviar de nuevo a las dependencias SQL que están preocupadas por los cambios en estos datos?

Se agradece mucho cualquier ayuda ... He estado recorriendo muchas referencias en línea y no puedo encontrar ninguna explicación concreta de esto.

Answer 1

Se crea una nueva tabla en su base de datos que contiene un nombre de la tabla en la que desea verificar las actualizaciones y un número de cambio. Cada tabla que tiene la configuración de SQLDependency tiene un desencadenante configurado para actualizaciones/insertos que incrementa el cambio en la nueva tabla que acabo de describir.

Su modelo mental de cómo funciona esto está al revés. Su aplicación verifica el registro para determinar si una tabla ha cambiado.

Entonces, si la tabla de ChangeLog (así es como lo llamo) es rastrear dos tablas en su base de datos (producto, usuario), se verá así.

+Table Name + ChangeNumber +
| Product   | 1            |
+-----------+--------------+
| User      | 1            |
+-----------+--------------+

Ahora, si modifica algo en cualquiera de estas tablas, el disparador se incrementará ChangeNumber Y ahora sabemos que cambiaron.

Obviamente, hay más en esto, pero esta es la idea general.

Nota: Cabe señalar que puede invalidar una página si una o más tablas cambian, por lo que si su página tiene dependencia configurada para ambas tablas, si una de ellas cambia, invalidará la página en caché y volverá a comer una actualización y actualizada versión.