Application vs Cache: Mecanismo de bloqueo

Question

La clase Application en asp.net tiene mecanismo Lock para admitir la seguridad del hilo.

Como sabemos, se puede acceder al Application de forma global.

muestra:

Application.Lock(); 
Application["MyCode"] = 21; 
Application.UnLock(); 

bien.

pero

También el Cache es accesible a nivel mundial (y tampoco tienen mecanismo de bloqueo y también se utiliza para eliminar/añadir elementos)

así que ¿por qué Application tiene un mecanismo de bloqueo y Cache no lo hace?

Answer 1

Application es un datastore restante de la tecnología ASP anterior. Tiene un bloqueo global único. Cuando llame al Application.Lock(), todos los accesos al objeto Aplicación en todos los hilos están bloqueados.

Por otro lado, el objeto más nuevo Cache que se introdujo con ASP.NET le permite usar su propia semántica de bloqueo. Puede usar la declaración lock de .NET para asegurar el acceso seguro a subprocesos al objeto Caché mientras mantiene su aplicación web lo más paralela posible. La instrucción lock es mucho más segura ya que se garantiza que el bloqueo se liberará cuando salga de un bloque lock. El objeto de la aplicación no garantiza eso. La memoria caché también proporciona mecanismos de expiración automática que es mucho más adecuado para, bueno, una memoria caché. También puede caducar las claves basadas en contratos de dependencia y prioridades opcionales que, por supuesto, carece de objeto de aplicación.

No veo ninguna razón para usar Application sobre Cache objeto.

Ejemplo: Supongamos que tiene cientos de elementos en la memoria caché y tiene un único elemento que desea almacenar en la memoria caché, si no está ya allí. Cuando se utiliza Application, esto se hace:

if(Application["someData"] == null) 
{ 
    Application.Lock(); 
    if(Application["someData"] == null) 
    { 
     Application["someData"] = getValue(); //a very long time consuming function 
    } 
    Application.Unlock(); 
} 

En este escenario todos los accesos al objeto de aplicación están bloqueados incluso si son completamente irrelevante. Y en el caso de que getValue() cause una excepción, su aplicación se cuelga porque no se libera el bloqueo. Debe envolver un try .. finally alrededor de eso para asegurarse de que sea seguro.

Por otra parte, cuando se utiliza un objeto Cache, esto se hace:

if(Cache["someData"] == null) 
{ 
    lock(myLockObject) // or other shared lock for that single value 
    { 
     if(Cache["someData"] == null) 
     { 
      Cache["someData"] = getValue(); 
     } 
    } 
} 

En este caso, sólo los bloques de código que requieren acceso a myLockObject estarían esperando. Otros que tengan acceso a Cache se ejecutarán en paralelo muy bien. Y en el caso de que getValue() arroje una excepción, su bloqueo se libera sin problemas, permitiendo que otros hilos continúen la ejecución.