multithreading - Bloqueo HttpRuntime.Cache para carga lenta

caching synchronization

Question

Tenemos un sitio web que ejecuta .NET 2.0 y hemos comenzado a usar ASP.Net HttpRuntime.Cache para almacenar los resultados de las búsquedas frecuentes de datos para reducir el acceso a nuestra base de datos.

Retazo:

lock (locker)
{
    if (HttpRuntime.Cache[cacheKey] == null)
    {
        HttpRuntime.Cache.Insert(cacheKey, GetSomeDataToCache(), null, DateTime.Today.AddDays(1), Cache.NoSlidingExpiration);       
    }
    return ((SomeData)HttpRuntime.Cache[cacheKey]).Copy();
}

Estamos pesimistamente bloqueados cada vez que queremos ver el caché. Sin embargo, he visto varios blogs publicados en la Web que sugieren que bloquee después de verificar el valor de caché, para no incurrir en la sobrecarga del bloqueo. Eso no parece correcto ya que otro hilo puede haber escrito en el caché después del cheque.

Entonces, finalmente, mi pregunta es ¿cuál es la forma "correcta" de hacer esto? ¿Estamos utilizando el objeto de sincronización de hilo correcto? Soy consciente de ReaderWriterLockSlim () pero estamos ejecutando .NET 2.0.

Answer 1

El objeto Cache en .NET es seguro para subprocesos, por lo que no es necesario bloquearlo. Referencia: http://msdn.microsoft.com/en-us/library/system.web.caching.cache.aspx .

Answer 2

Hasta donde yo sé, el objeto Caché es seguro para subprocesos, por lo que no necesitarías el bloqueo.

Answer 3

A salvo de amenazas. ¿Significa que todos los demás procesos están esperando que su código finalice?

El hilo seguro es que puede estar seguro de que el artículo que busca no será "cortado por la mitad" o parcialmente demolido por una actualización de la caché al mismo tiempo que está leyendo el artículo.

item = cache.Get(key);

Pero cualquier cosa que hagas después de eso, otro hilo puede operar en el caché (o cualquier otro recurso compartido). Si desea hacer algo con la memoria caché en función de que el elemento que ha obtenido sea nulo o no, no estaría 100% seguro de que ya no está solucionado por otra instancia de su propio código como unas pocas instrucciones de la CPU que preste servicio a otro lector de la misma página de su revista de motor en línea.

Necesitas mala suerte. El riesgo de que otros procesos se preocupen por el mismo objeto de caché, no atómico, en unas pocas líneas de código, es aleatoriamente pequeño. Pero si sucede, te costará entender por qué la imagen del Chevy es a veces la pequeña maleta de la página dos.

Answer 4

Es probable que su código lo haga pensar que tendrá ese elemento en la memoria caché por 1 día y su última línea siempre le dará esos datos, pero ese no es el caso. Como otros dijeron, las operaciones de caché están sincronizadas, por lo que no debe bloquear en ese punto.

Echa un vistazo aquí para ver la forma correcta de hacerlo .