problemas con la cache de Linqtosql

Hola Alfredo,

On 6 okt, 12:08, Alfredo Novoa wrote:

El Sun, 5 Oct 2008 11:57:01 -0700, Carlos M. Calvelo escribió:

> Me refería a la idea de que si el SGBD puede notificar a linq, o
> en general a cualquier conexión (aplicación), de los cambios en los
> datos ya extraidos por la misma aplicación en transacciones
> anteriores, entonces casi tienen sentido los ejemplos de los enlaces
> que has puesto sobre concurrencia.

Ah, eso. Pues me parece que eso sería mucho pedir para esta gente, pero
claro que sería la forma lógica de resolver las actualizaciones de los
datos en memoria, y no solo de la fila que se está editando en ese momento.

Yo eso aun lo tengo a medio implementar, pero necesito usar 3 capas y tiene
su complicación hacerlo bien. Solo funcionaría si todas las aplicaciones se
conectan al servidor intermedio y ninguna directamente a SQL Server.

Pues suerte con ello. Para hacerlo bien sería como mantener una
administración por conexión de todas las consultas con sus
resultados y "tratar de constatar"! como estos resultados cambian
a consecuencia de actualizaciones desde otras conexiones (o la
misma). Y diseñar un protocolo. Esta capa envía una notificación a
las aplicaciones de que ciertos resultados han cambiado y la
aplicación reacciona a eso. O simplemente envía el nuevo resultado.
Las conexiones deberían también notificar que a partir de cierto
momento no tienen más interés en los cambios en resultados de
ciertas consultas anteriores, etc, etc. Cierto dato puede formar
parte de resultados de consultas distintas desde conexiones distintas
o puede formar parte de los datos necesarios para derivar otro.
Ufff! Complicada la cosa! (Estoy pensando en el patrón MVC.)

Pero estaría bien. Podrías estar viendo como los datos presentados
en una pantalla cambian a consecuencia de actualizaciones desde
otras aplicaciones. :-)

Teniendo en cuenta que algunas aplicaciones no se conectan por
medio de esta capa intermedia, se podría ofrecer la posibilidad
de actualizar los datos pidiendolos de nuevo al SGBD en momentos
en que esta capa y el SGBD estén 'idle', por ejemplo. Cosa que
también podrían hacer las aplicaciones y nos ahorraríamos todo
esto. :-)

> Pero ese control seguiría siendo
> innecesario porque seguiría siendo responsabilidad del SGBD.

Es que eso no es control de concurrencia, es simplemente como se actualizan
los datos cargados en la memoria de las aplicaciones.

Cierto. Parece que quise decir que si lo es, pero no me he expresado
muy bien. Pero fué lo primero que se me ocurrió al ver los ejemplos
en los enlaces que has puesto. Con un mechanismo de actualización
así es obvio que lo que se explica como conflictos de concurrencia,
no lo son.

Saludos,
Carlos

Hola Carlos,

El Mon, 6 Oct 2008 07:33:27 -0700 (PDT), Carlos M. Calvelo escribió:

Teniendo en cuenta que algunas aplicaciones no se conectan por
medio de esta capa intermedia,

La idea es que todas se conecten a través de la capa intermedia.

se podría ofrecer la posibilidad
de actualizar los datos pidiendolos de nuevo al SGBD en momentos
en que esta capa y el SGBD estén 'idle', por ejemplo.

¿Y como puedo saber si el SQL Server está ocioso?

A mi esto me parece bastante cutre. Aquí ya hemos tenido malas experiencias
con eso. Si pones las actualizaciones muy seguidas puedes sobrecargar
fácilmente el servidor si hay muchos clientes conectados, y si las pones
muy espaciadas entonces casi no sirven para nada, y siempre tienes el
problema de si dos usuarios actualizan la misma fila casi a la vez.


Saludos

Hola Alfredo,

On 7 okt, 13:02, Alfredo Novoa wrote:

Hola Carlos,

El Mon, 6 Oct 2008 07:33:27 -0700 (PDT), Carlos M. Calvelo escribió:

> Teniendo en cuenta que algunas aplicaciones no se conectan por
> medio de esta capa intermedia,

La idea es que todas se conecten a través de la capa intermedia.

Lo ponía como escapatoria por si se quiere considerar esa opción,
como excepción. Claro que lo mejor es considerar que esa capa
intermedia es el SGBD y que a nivel lógico SQL Server (o lo que sea)
no existe (seguimos con las dos capas de siempre).

> se podría ofrecer la posibilidad
> de actualizar los datos pidiendolos de nuevo al SGBD en momentos
> en que esta capa y el SGBD estén 'idle', por ejemplo.

¿Y como puedo saber si el SQL Server está ocioso?

A mi esto me parece bastante cutre. Aquí ya hemos tenido malas experiencias
con eso. Si pones las actualizaciones muy seguidas puedes sobrecargar
fácilmente el servidor si hay muchos clientes conectados, y si las pones
muy espaciadas entonces casi no sirven para nada, y siempre tienes el
problema de si dos usuarios actualizan la misma fila casi a la vez.

Pues sí. Sería bastante cutre. :-)
Estoy de acuerdo en que es mejor exigir que todas las aplicaciones
se conecten a esa capa 'intermedia'.

Saludos,
Carlos