problemas con la cache de Linqtosql

24/09/2008 - 13:22 por [Juanjo] | Informe spam
hola gente:

Tengo el siguiente problema, estoy seguro de que es una tonteria, pero
no doy.

tengo una aplicacion que accede a una base de datos SQL server con LINQ.

Cuando realizo esto:
1. Ejecuto 2 veces la misma aplicacion.
2. Accedo al mismo registro de la misma base de datos desde las dos
ejecuciones
3. Desde una ejecucion modifico algun dato
4. Desde la otra ejecucion vuelvo a recuperar el mismo registro
5. Esta ultima ejecucion no "ve" los cambios efectuados.

Alguien sabe como limpiar la cache?

Muchas gracias

Preguntas similare

Leer las respuestas

#26 Carlos M. Calvelo
06/10/2008 - 16:33 | Informe spam
Hola Alfredo,

On 6 okt, 12:08, Alfredo Novoa wrote:
Mostrar la cita
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. :-)


Mostrar la cita
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
#27 Alfredo Novoa
07/10/2008 - 13:02 | Informe spam
Hola Carlos,

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

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

Mostrar la cita
¿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
#28 Carlos M. Calvelo
07/10/2008 - 14:13 | Informe spam
Hola Alfredo,

On 7 okt, 13:02, Alfredo Novoa wrote:
Mostrar la cita
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).


Mostrar la cita
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
Ads by Google
Search Busqueda sugerida